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Prologue 


This  document,  STARS  Conceptual  Framework  for  Reuse  Processes  (CFRP),  Volume  II:  Appli¬ 
cation,  Version  1.0,  is  Volume  II  of  the  two-volume  STARS  CFRP  document  set.  It  provides 
initial  guidance  in  how  to  apply  the  STARS  CFRP,  as  defined  in  the  companion  volume,  STARS 
Conceptual  Framework  for  Reuse  Processes  (CFRP),  Volume  I:  Definition,  Version  3.0. 

Both  CFRP  volumes  wUl  be  revised  and  re-released  periodically  to  reflect  the  lessons  learned  in 
defining  and  applying  the  CFRP  and  to  address  comments  from  reviewers  of  the  documents,  both 
internal  and  external  to  STARS. 

We  thus  encourage  trial  application  of  the  CFRP  and  solicit  reader  review  and  comments  as  input 
to  future  revisions  of  both  volumes.  Please  submit  comments  to: 


CFRP  Comments 
c/o  Dick  Creps 

Unisys  Government  Systems  Group 
Dept.  7670 

12010  Sunrise  Valley  Drive 
Reston,  VA  22091 

Phone:  (703)  620-7100 
Fax:  (703)  620-7916 

E-mail:  cfrp@stars.ballston.paramax.com 
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1  Introduction 


This  document  was  produced  by  the  Software  Technology  for  Adaptable,  Reliable  Systems  (STARS) 
program  on  behalf  of  the  U.S.  Department  of  Defense  (DoD)  Advanced  Research  Projects  Agency 
(ARPA).  The  document  was  developed  by  a  STARS  working  group  consisting  of  members  from 
each  of  the  STARS’  prime  contractor  teams,  the  MITRE  Corporation,  and  the  Hewlett-Packard 
Company  (a  STARS  Technology  Transition  Affiliate). 

This  document  is  Volume  II  of  a  two  volume  set.  The  other  volume,  STARS  Conceptual  Framework 
for  Reuse  Processes  (CFRP),  Volume  /;  Definition,  Version  3.0  [Sof93d],  defines  the  STARS  CFRP. 
Volume  II  directly  supplements  Volume  I  by  providing  initial  guidance  in  how  the  CFRP  can  be 
applied.  It  is  thus  essential  that  Volume  I  be  read  before  reading  Volume  II.  It  is  also  recommended 
that  Volume  I  be  readily  available  and  consulted  frequently  as  a  reference  while  reading  Volume  II. 

Throughout  the  remainder  of  this  document.  Volume  I  will  often  be  referred  to  informally  as 
the  “CFRP  Definition  document”,  and  Volume  II  will  be  referred  to  as  the  “CFRP  Application 
document” . 


1.1  Purpose 

The  CFRP  Definition  document  provides  a  complete  definition  of  the  abstract  CFRP  model.  How¬ 
ever,  it  provides  little  concrete  guidance  to  assist  someone  in  interpreting  and  tailoring  the  CFRP 
to  support  reuse  program  and  project  planning.  The  primary  purpose  of  the  CFRP  Application 
document  is  to  provide  such  guidance,  in  preliminary  form,  to  potential  users  of  the  CFRP.  A  sec¬ 
ondary  document  objective,  through  providing  such  guidance,  is  to  promote  further  understanding 
of  the  CFRP  and  its  underlying  reuse  concepts.  A  third  objective  of  the  document  is  to  indicate 
how  existing  reuse  processes  and  tools  relate  to  the  CFRP  by  mapping  a  representative  sampling 
of  such  products  to  the  CFRP  families  to  which  they  apply. 


1.2  Audience 

This  document  is  targeted  to  readers  having  one  or  more  of  the  following  roles  in  their  organizations: 


•  Program/Project  Planner  -  Responsible  for  planning  the  objectives,  strategy,  processes,  in¬ 
frastructure,  and  resources  for  software  engineering  programs  or  projects.  Interested  in  in¬ 
corporating  domain-specific  reuse  into  those  programs  or  projects. 

•  Process  Engineer  -  Responsible  for  defining,  instantiating,  tailoring,  monitoring,  administer¬ 
ing,  and  evolving  software  engineering  process  models.  Interested  in  defining  reuse  processes 
or  integrating  them  with  overall  life  cycle  process  models. 

•  Reuse  Advocate  -  Responsible  for  keeping  abreast  of  reuse  concepts,  technology,  and  trends 
and  promoting  the  establishment  or  improvement  of  reuse  capabilities  and  practices  within  an 
organization.  Interested  in  understanding  how  new  concepts  and  technology  can  be  applied 
to  accelerate  reuse  adoption. 
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Different  portions  of  this  document  may  appeal  most  strongly  to  one  segment  of  the  audience  or 
another.  However,  the  entire  document  should  be  of  some  interest  to  all  readers,  because  all  the 
audience  segments  are  interdependent  and  each  can  benefit  from  the  broad  range  of  perspectives 
presented  in  the  document. 


1.3  Context  and  Approach 

The  CFRP  has  been  developed  and  put  forth  to  provide  a  process-oriented  organizing  framework 
for  STARS  reuse  work  and  to  articulate  a  set  of  common  basic  concepts  underlying  process-driven, 
domain-specific  reuse-based  approaches  to  software  engineering.  It  is  based  on  the  STARS  vision 
and  mission,  recent  trends  in  orgr*'iza.tional  theory  and  management,  and  recent  advances  in  reuse 
technology  and  practice.  It  reflecio  a  consensus  view  of  the  authors,  based  on  their  own  experience, 
feedback  from  individual  reviewers  and  workshop  working  groups,  and  lessons  learned  through  early 
CFRP  application. 

The  CFRP  has  been  applied  in  several  limited  ways  to  date  and  is  now  being  applied  more  substan¬ 
tially  by  the  STARS  demonstration  projects  and  STARS  Reuse  Technology  Transition  Affiliates. 
In  these  contexts,  the  CFRP  is  providing  overall  organizing  principles  and  is  supporting  reuse 
project  planning,  life  cycle  process  definition,  and  the  selection  and  detailed  definition  of  specific 
reuse-related  processes.  These  triad  applications  have  yielded,  and  will  continue  to  yield,  feedback 
that  supports  further  evolution  of  the  CFRP  and  aidditional  understanding  of  how  the  CFRP  can 
be  applied  in  practice.  However,  the  more  ambitious  and  sophisticated  of  these  CFRP  application 
efforts  are  still  in  progress  and  the  results  are  stUl  largely  undocumented. 

In  the  absence  of  substantial  documented  experience  in  the  practical  application  of  the  CFRP, 
it  is  premature  to  provide  formal,  definitive  guidance  for  using  the  CFRP  at  this  time.  Instead, 
the  first  version  of  this  document  offers  informal,  suggestive  guidance,  primarily  in  the  form  of 
examples  that  illustrate  how  the  CFRP  can  be  used.  The  document  includes  a  discussion  of 
general  CFRP  application  principles,  a  set  of  scenarios  illustrating  those  principles  in  practice,  a 
brief  summary  of  experiences  with  the  CFRP  to  date  and  an  initial  set  of  informal  guidelines  based 
on  those  experiences,  an  example  process  model  that  elaborates  on  the  information  flow  among 
CFRP  processes,  and  mappings  between  the  CFRP  and  existing  reuse  products. 

As  a  result  of  feedback  from  current  and  future  CFRP  application  efforts,  future  versions  of  this 
document  may  include  more  definitive  guidance,  possibly  including  a  wefl  defined  process  or  pro¬ 
cesses  for  applying  the  CFRP  in  various  ways,  supported  by  concrete,  detailed  examples  and  case 
studies. 


1.4  Document  Organization 

This  document  is  organized  as  follows: 

•  Section  1  (this  section)  provides  introductory  material  that  establishes  the  document  context, 
purpose,  audience,  and  approach. 
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•  Section  2  presents  general  CFRP  application  principles,  with  brief  descriptions  of  specific  sug¬ 
gested  types  of  usage,  discussion  of  specific  CFRP  process  modeling  techniques,  and  examples 
illustrating  those  techniques. 

•  Section  3  includes  four  moderately  detailed  scenarios  providing  concrete,  practical  illustrations 
of  different  ways  in  which  the  CFRP  can  be  applied. 

•  Section  4  summarizes  experience  with  the  CFRP  to  date  and  offers  a  brief  set  of  preliminary 
guidelines  for  getting  started  with  the  CFRP. 

•  Appendix  A  provides  a  high-level  CFRP  process  model,  expressed  in  the  form  of  IDEFo 
diagrams  and  an  associated  data  dictionary,  that  shows  one  interpretation  of  the  information 
flows  among  CFRP  process  idioms,  families,  and  categories. 

•  Appendix  B  provides  tables  that  map  existing  STARS  and  non-STARS  reuse  products  to  the 
CFRP  process  families  to  which  they  apply. 

•  The  References  section  provides  bibliographic  entries  for  all  documents  referenced  in  this 
document. 
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2  CFRP  Application  Principles 


The  CFRP  Definition  document  defines  the  CFRP  as  an  abstract  model  consisting  of  a  set  of 
individual  elements  (reuse  process  idioms,  families,  and  categories)  and  their  high-level  interrela¬ 
tionships.  This  section  defines  a  set  of  general  principles  for  how  this  abstract  model  can  be  applied 
in  practice  by  planners,  managers,  and  engineers  involved  in  establishing  and  evolving  reuse  capa¬ 
bilities  within  their  organizations.  The  section  describes  some  general  approaches  for  applying  the 
CFRP,  discusses  a  set  of  process  modeling  techniques  that  can  be  used  in  the  CFRP  context,  and 
offers  examples  illustrating  those  techniques. 


2.1  General  Approaches  for  Applying  the  CFRP 

Because  the  CFRP  forms  a  strongly  interconnected,  cohesive  system  for  describing  and  classifying 
reuse  processes,  it  may  appear  to  prescribe  a  particular  approach  to  reuse.  However,  the  CFRP 
is  designed  to  be  generic  with  respect  to  specific  domains,  organizational  structures,  economic 
sectors,  life  cycle  models,  detailed  methods,  and  implementation  technologies.  While  it  captures  the 
essential  characteristics  and  interrelationships  of  domain-specific  reuse-based  software  engineering 
processes,  and  thus  is  not  “policy-free” ,  it  does  not  legislate  beyond  those  essential  qualities;  it  leaves 
decisions  about  the  organization-specific  details  of  reuse  programs  and  processes  to  the  CFRP  user. 

To  the  extent  that  the  CFRP  does  prescribe  an  approach,  it  embodies  certain  concepts  that  add 
significant  value  relative  to  not  only  conventional  software  engineering  practices,  but  also  most 
current  approaches  to  managed  reuse.  In  particular,  the  CFRP  explicitly  emphasizes  certain  aspects 
of  reuse  that  are  often  ignored  or  left  implicit  in  most  reuse  approaches. 

For  example,  several  reuse  process  models  (e.g.,  [BM91,  Vir92a])  distinguish  between  domain  en¬ 
gineering  and  application  engineering  groups  within  organizations,  but  they  neither  call  out  Asset 
Management  as  a  logically  distinct  function,  nor  address  the  implications  of  bundling  Asset  Man¬ 
agement  functions  with  either  Asset  Creation  or  Asset  Utilization.  The  CFRP  could  be  used  to 
describe  a  life  cycle  built  in  accordance  with  such  a  two-functioned  model,  but  would  force  the 
explicit  documentation  of  where  within  the  overall  organization  Asset  Management  was  being  per¬ 
formed,  and  why. 

Another  distinctive  aspect  of  the  CFRP  is  its  explicit  recognition  of  the  role  of  learning  as  funda¬ 
mental  to  managed  reuse.  Few  current  reuse  approaches  (e.g.,  [BCC92])  treat  learning  processes 
explicitly  or  even  acknowledge  them  as  important.  Most  approaches  either  ignore  the  role  of  learn¬ 
ing  in  reuse,  address  it  implicitly  in  various  ways,  or  just  assume  that  reuse  learning  will  happen 
as  a  result  of  institutional  process  improvement  or  quality  assurance  measures  that  are  not  directly 
integrated  with  reuse  processes. 

Because  of  these  distinguishing  CFRP  characteristics,  the  use  of  the  CFRP  (e.g.,  in  assessing  and 
evolving  existing  reuse  capabilities  or  establishing  new  capabilities)  wUl  often  yield  results  that 
are  qualitatively  different  from  those  that  would  be  produced  using  an  ad  hoc  approach  or  other 
reuse-oriented  approaches. 
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Some  of  the  specific  ways  in  which  the  CFRP  can  be  used  include; 


Reuse  assessment  and  classification 

The  CFRP  can  be  viewed  as  a  descriptive  domain  model  of  reuse  processes.  It  can  thus  be 
used  as  a  kind  of  standard  against  which  to  assess  and  classify  software  engineering  products 
in  terms  of  the  reuse  processes  they  reflect  or  support.  Such  products  could  include  process 
models  or  descriptions,  program  or  project  plans,  project  results,  tools,  assets,  and  so  on. 

For  example,  organizations  can  use  the  CFRP  to  assess  their  current  software  engineering 
practices  and  infrastructure  to  help  them  understand  the  strengths  and  weaknesses  of  their 
current  reuse  capabilities.  Similarly,  they  can  use  the  CFRP  to  assess  proposed  plans,  pro¬ 
cesses,  and  tools  for  completeness  and  consistency.  Organizations  can  also  use  the  CFRP 
to  communicate  the  characteristics  of  reuse  products  or  capabilities  to  others  by  classifying 
them  in  terms  of  the  CFRP  families  or  categories  they  address. 

Reuse  program  and  project  planning 

The  CFRP  can  support  planning  in  a  variety  of  forms  and  at  a  variety  of  levels.  In  general, 
the  CFRP  plays  two  key  roles  in  planning:  (1)  To  guide  the  reuse  planning  process  itself,  and 
(2)  To  give  planners  information  about  the  reuse-relevant  activities  they  are  planning.  The 
CFRP  can  impact  the  planning  of  specific  activities  in  significant  detail,  but  it  cau  also  have 
impact  simply  by  conveying  a  general  set  of  reuse-oriented  principles. 

The  CFRP  can  be  useful  in  high-level  strategic  planning  by,  for  example,  providing  insight 
into  the  role  reuse  can  play  in  long-term  investment  strategies  and  indicating  how  reuse  can 
help  build  competitive  advantage.  The  CFRP  can  directly  assist  reuse  program  planners  by 
guiding  their  planning  processes  and  by  giving  them  a  framework  for  flexibly  structuring  reuse 
programs  in  terms  of  the  CFRP  idioms  and  families.  The  CFRP  provides  the  project  planner 
with  similar  assistance,  typically  more  at  the  process  category  level,  by  giving  the  planner 
insight  into  specific  reuse  activities  that  need  to  be  performed.  Such  assistance  scales  down 
to  the  level  of  the  individual  engineer,  as  well,  who  can  use  CFRP  concepts  and  principles  to 
help  plan  his  or  her  daily  work. 

Reuse  process  engineering 

The  CFRP  can  be  viewed  as  a  high-level  process  model.  It  defines  a  set  of  generic  process 
elements  and  provides  significant  information  about  how  those  elements  interrelate.  The 
CFRP  can  thus  be  very  useful  to  process  engineers  who  are  interested  in  defining  or  modeling 
reuse  processes  and  their  interactions.  The  CFRP  can  also  help  with  integrating  reuse  into 
overall  life  cycle  processes  by  providing  a  general  set  of  Asset  Utilization  process  categories 
that  is  readily  adaptable  to  any  life  cycle  product  or  phase. 

In  addition,  the  CFRP  addresses  process  issues  from  a  different  perspective  by  defining  a  gen¬ 
eralized  approach  to  process  (and  product)  improvement  via  the  Reuse  Management  idiom. 
The  CFRP  may  thus  be  of  interest  to  process  improvement  groups  within  an  organization 
because  of  its  integrated  approach  to  planning,  learning,  metrics,  innovation,  and  infrastruc¬ 
ture. 


The  use  of  the  CFRP  in  any  specific  context  should  reflect  the  needs  and  circumstances  of  the 
organization(s)  in  which  it  is  being  applied.  For  example,  an  organization  needn’t  embrace  all 
aspects  of  the  CFRP  at  once.  It  may  make  sense  in  many  organizations  to  adopt  reuse  in  a  gradual 
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fashion,  by  limiting  the  scope  of  initial  reuse-based  projects  (e.g.,  by  assuming  assets  are  created 
outside  the  organization,  and  thus  not  sponsoring  internal  Asset  Creation  projects)  or  by  phasing 
CFRP  Reuse  Management  processes  into  the  organization’s  overall  way  of  doing  business  in  an 
incremental  fashion  over  a  period  of  time. 


2.2  CFRP  Process  Modeling  Techniques 

The  CFRP  can  be  applied  in  a  number  of  useful  ways  without  taking  full  advantage  of  its  inherent 
flexibility  and  adaptability.  However,  when  the  CFRP  is  used  as  a  basis  for  process  modeling,  as 
is  often  the  case  in  a  planning  or  process  engineering  context,  the  full  benefits  of  the  CFRP  can 
only  be  achieved  by  understanding  and  applying  some  or  all  of  the  following  CFRP  modeling  and 
adaptation  techniques: 


•  Tailoring  of  CFRP  process  categories  so  that  they  will  be  applicable  in  some  specific  context 

•  Composition  of  CFRP  process  idioms  and  families  to  produce  arbitrary  CFRP-consistent 
process  configurations 

•  Integration  of  CFRP  elements  with  other  process  elements  to  form  new  process  models,  typ¬ 
ically  with  broader  life-cycle  coverage 

•  Instantiation  of  process  elements  via  allocation  to  organizational  entities 


The  following  paragraphs  discuss  these  techniques  in  more  detail. 


Tailoring 

The  CFRP  process  categories,  as  defined  in  the  CFRP  Definition  document,  may  not  be  entirely 
applicable  in  some  organizational  contexts.  While  many  processes  in  an  organization  might  cor¬ 
respond  clearly  to  specific  CFRP  categories,  other  organization  plans  or  processes  may  justify 
addition  of  new  process  categories.  These  will  typically  involve  categories  that  are  believed  to 
be  reuse-specific,  but  are  not  included  in  the  current  CFRP.  Alternatively,  all  of  the  categories 
within  one  or  more  CFRP  families  could  be  reconfigured  or  repartitioned  to  reflect  different  per¬ 
spectives  on  reuse  within  the  organization.  In  addition,  any  categories  deemed  inappropriate  could 
be  eliminated  or  modified.  These  kinds  of  adjustments  to  the  CFRP  process  category  structure  are 
collectively  called  CFRP  “tailoring”.  Such  tailoring  could  be  done  anew  each  time  the  CFRP  is  ap¬ 
plied,  or  modelers  could  create  a  persistent  tailored  version  of  the  CFRP  incorporating  a  variety  of 
organization-specific  assumptions,  which  could  then  be  reused  as  the  basis  for  future  CFRP -based 
process  modeling  activities  within  the  organization. 

As  noted  in  the  CFRP  Definition  document  (in  the  introductory  portion  of  the  CFRP  Descrip¬ 
tion  section),  the  CFRP  process  idiom  and  family  structure  is  considered  fundamental  to  CFRP 
semantics,  whereas  the  categories  are  viewed  zis  more  arbitrary,  and  thus  more  adaptable.  The 
CFRP  tailoring  techniques  are  thus  generally  applicable  only  at  the  process  category  level,  since 
they  focus  on  adding,  modifying,  deleting,  and  repartitioning  CFRP  elements. 
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Composition 

Although  the  tailoring  techniques  are  useful  for  adapting  CFRP  process  categories  to  organizational 
needs,  greater  expressive  power  is  needed  to  configure  the  CFRP  idioms  and  families  to  reflect 
sophisticated  reuse-specific  process  interactions.  This  power  is  provided  by  the  CFRP  composition 
techniques  (e.g.,  linkage,  recursion,  cascading),  which  enable  the  idioms  and  families  to  be  connected 
together  to  produce  arbitrary  CFRP  configurations.  Such  configurations  can  represent  a  wide 
range  of  interesting  relationships  and  interconnections  among  CFRP  elements.  The  composition 
techniques  are  considered  an  intrinsic  part  of  the  CFRP  model,  and  are  thus  described  in  detail  in 
Appendix  A  of  the  CFRP  Definition  document,  rather  than  in  this  document. 

CFRP  configurations  can  represent  models  ranging  from  the  very  concrete  (a  project  plan  involving 
specific  organizations,  individuals,  and  processes,  interacting  in  specific  ways)  to  the  relatively 
abstract  (a  reuse  process  model  that  standardizes  certain  recurring  processes  and  policies,  but 
must  be  integrated  with  a  life  cycle  model  and  instantiated  for  each  project),  for  example,  an 
organization  that  wants  to  establish  a  separate  Asset  Management  effort  to  manage  rach  major 
type  of  asset  in  its  software  life  cycle  (i.e.,  establish  distinct  libraries  for  reusable  requirements, 
designs,  code,  test  cases,  etc.)  might  develop  a  generic  CFRP  configuration  reflecting  this  policy. 
Individual  Asset  Creation  or  Asset  Utilization  (i.e.,  application  engineering)  pro|e«i»  »ould  then 
integrate  and  instantiate  this  organization-wide  model  within  their  project  plans 


Integration 

Since  the  CFRP  contains  only  process  elements  relevant  to  reuse,  these  elements  must  \w  integrated 
with  non-reuse-specific  processes  to  form  overall  life  cycle  process  models.  This  integration  can  be 
approached  in  either  (or  often  both)  of  the  following  complementary  ways: 

•  embedding  non-CFRP  processes  within  a  CFRP  process  model,  or 

•  embedding  CFRP  processes  within  an  existing  non-CFRP  process  model. 

As  an  example  of  the  first  approach,  existing  validation  and  verification  processes  that  are  applied 
throughout  the  organization  in  a  single-system  context  could  be  integrated  with  Asset  Creation 
processes  to  impose  organization-standard  V&V  procedures  for  created  assets.  Another  example  of 
the  first  approach,  from  the  Reuse  Management  perspective,  is  that  any  engineering  process  could 
be  enacted  using  the  CFRP  Plan-Enact-Leam  paradigm.  In  this  sense,  the  Reuse  Management 
idiom  can  aid  in  planning,  enacting,  and  deriving  lessons  learned  from  any  engineering  process. 

As  an  example  of  the  second  approach.  Asset  Utilization  processes  could  be  embedded  within  the 
various  steps  of  an  existing  application  engineering  life  cycle  to  effect  reuse  in  each  life  cycle  stage 
in  ways  that  are  appropriate  for  the  domain  and  for  the  system  being  engineered. 

In  either  of  the  above  integration  approaches,  the  processes  with  which  the  CFRP  is  being  inte¬ 
grated  should  be  analyzed  to  identify  overlaps  and  gaps  relative  to  the  CFRP,  to  help  guide  the 
integration  process.  This  analysis  and  the  subsequent  integration  should  be  subject  to  certain 
CFRP  constraints.  In  particular,  each  CFRP  idiom  and  family  should  appear  in  the  integrated 
process,  or  their  absence  should  be  explicitly  justified  (e.g,  by  acknowledging  that  the  processes  in 
one  or  more  of  the  Reuse  Engineering  families  is  being  performed  outside  the  organization).  The 
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Reuse  Learning  and  Asset  Management  families  are  important,  distinctive  CFRP  features,  and 
inclusion  of  these  functions  is  a  recommended  CFRP  modeling  constraint. 


Instantiation 

The  CFRP  is  designed  to  make  minimal  assumptions  about  where  organizational  boundaries  might 
fall  within  or  between  idioms  and  families.  The  intent  of  the  idioms  is  to  capture  essential  aspects 
of  a  reusable  engineering  process  that  remain  invariant  whether  that  process  is  enacted  by  a  single 
individual,  a  single  organization,  or  a  collection  of  interacting  organizations. 

Thus,  to  make  a  CFRP  model  fully  applical  le  within  an  organization,  each  idiom  or  family  must 
be  “instantiated”  to  represent  performance  of  the  CFRP  functions  by  an  individual  worker,  project 
team,  or  larger-scale  organization.  A  single  organizational  unit  may  take  responsibility  for  the 
processes  encompassed  by  several  CFRP  families.  Alternatively,  the  functions  of  one  CFRP  element 
can  be  distributed  across  different  organizations,  different  divisions  within  an  organization,  or 
different  individuals  in  a  small  development  group  (depending  on  the  level  at  which  the  CFRP 
is  being  applied).  For  example,  the  CFRP  could  be  applied  to  an  organization  that  maintains  a 
single  large  asset  base  serving  multiple  domain-oriented  reuse  projects,  or  to  an  organization  that 
decides  to  maintain  separate  asset  bases  for  reusable  assets  from  different  parts  of  the  software  life 
cycle.  As  an  example  of  family  interactions  that  can  be  distributed  across  scopes  of  planning,  one 
organization  can  create  assets,  a  second  organization  can  manage  those  assets  (and  perhaps  other 
assets  from  a  variety  of  sources),  and  a  third  organization  can  utilize  those  managed  assets. 

If  the  process  model  being  instantiated  includes  non-reuse-specific  elements  (resulting  from  appli¬ 
cation  of  the  CFRP  integration  techniques  discussed  above),  the  instantiation  operation  should 
generally  be  applicable  to  both  the  reuse-specific  and  non-reuse-specific  elements  of  the  model. 


2.3  CFRP  Process  Modeling  Examples 

To  put  the  above  techniques  in  more  concrete  terms,  two  examples  are  presented  below. 

Figure  1  illustrates  a  high-level  process  model  that  reflects  CFRP  tailoring  and  integration  tech¬ 
niques.  The  model  is  divided  into  separate  Domadn  Engineering  and  Application  Engineering  life 
cycles  (forming  a  so-called  “dual  life  cycle”  model).  Intervening  between  the  activities  in  the  respec¬ 
tive  life  cycles  is  an  Asset  Management  layer,  in  which  no  specific  activities  are  identified.  (Note 
that  the  diagram  leaves  other  aspects  of  the  model  unspecified,  as  well.  For  example,  no  flows  of 
information  indicating  feedback  or  learning  are  shown  explicitly.) 

The  Application  Engineering  life  cycle  illustrates  CFRP  integration,  because  the  implication  in 
the  diagram  is  that  Asset  Utilization  processes  are  integrated  with  (specifically,  embedded  within) 
conventional  life  cycle  activities  to  ensure  that  assets  created  by  the  indicated  Domain  Engineering 
activities  are  reused  when  constructing  applications.  The  Domain  Engineering  life  cycle  illustrates 
CFRP  tailoring,  because  the  CFRP  Domain  Analysis,  Domain  Architecture  Development,  and 
Asset  Implementation  process  categories  are  tailored  specifically  to  create  assets  to  be  reused  by  a 
corresponding  set  of  Application  Engineering  life  cycle  activities.  In  particular.  Domain  Analysis 
is  tailored  to  produce  requirements  assets  (or  at  least  requirements  guidance)  for  the  application 
analysis  activity,  and  Asset  Implementation  is  tailored  to  focus  specifically  on  code  component 
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Figure  1:  Example  of  CFRP  Tailoring  and  Integration  Techniques 


and  generator  development.  Of  the  three  Domain  Engineering  activities,  Domain  Architecture 
Development  appears  to  be  interpreted  most  consistently  with  its  corresponding  process  category 
description  in  the  CFRP  Definition  document. 

Figure  2  shows  a  different  view  of  the  same  situation  depicted  in  Figure  1,  reflecting  the  use  of 
CFRP  composition  and  instantiation  techniques.  The  diagram  illustrates  CFRP  nesting/recursion 
techniques  by  showing: 


•  an  outer  Reuse  Management  idiom  representing  a  high  level  reuse  program, 

•  a  set  of  Reuse  Management  idioms  defined  recursively  within  the  outer  idiom,  each  represent¬ 
ing  lower  level  scopes  of  planning  responsible  for  Domain  Engineering,  Asset  Management, 
and  Application  Engineering,  respectively,  and 

•  a  set  of  Domain  Engineering  (Asset  Creation),  Asset  Management,  and  Application  Engi¬ 
neering  (Asset  Utilization)  projects  nested  within  the  inner  Reuse  Management  idioms,  each 
performing  the  appropriate  processes  depicted  in  Figure  1. 


CFRP  linkage  techniques  are  shown  by  the  arrows  connecting  the  Asset  Creation,  Management, 
and  Utilization  activities  to  identify  the  general  flow  of  assets  within  the  reuse  program. 
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Figure  2:  Example  of  CFRP  Composition  and  Instantiation  Techniques 


Although  the  diagram  contains  no  organizational  labels,  it  can  readily  be  interpreted  as  an  in¬ 
stantiation  of  the  CFRP  representing  the  hierarchical  organizational  structure  of  an  overall  reuse 
program.  The  outer  Reuse  Managemer.t  idiom  in  this  example  represents  a  reuse  program  at 
the  division  level  within  a  company.  The  inner  Reuse  Management  idioms  represent  departments 
within  the  division,  responsible  for  managing  groups  of  projects  performing  distinct  kinds  of  Reuse 
Engineering  activities.  The  Reuse  Engineering  families  in  the  diagram  represent  distinct  project 
organizations  within  the  departments,  focusing  on  particular  domains,  libraries,  and  applications. 


Appendix  A  provides  a  different  kind  of  CFRP  process  modeling  example,  using  the  IDEFq  notation. 
This  model  offers  one  interpretation  of  the  data  flows  among  CFRP  idioms,  families,  and  categories, 
consistent  with  the  canonic  CFRP  described  in  the  CFRP  Definition  document.  Organizations  can 
use  this  model  directly  as  a  basis  for  additional  IDEFq  CFRP  modeling  (e.g.,  modeling  the  CFRP 
in  more  detail  or  modeling  alternative  CFRP  configurations).  They  can  also  tailor  the  model  by 
developing  alternative  interpretations  of  the  process  categories  and  data  flows,  or  they  can  integrate 
the  model  (or  any  tailored  version  thereof)  with  existing  IDEFq  process  models. 
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3  CFRP  Application  Scenarios 


This  section  presents  four  scenarios  that  illustrate  the  use  of  the  CFRP  in  several  practical  contexts. 
The  scenarios  provide  examples  of  how  the  CFRP  can  be  used  to  influence  the  nature  of  reuse- 
oriented  software  engineering  activities  and  support  various  types  of  planning  and  management 
tasks.  The  scenarios  are  presented  here  not  to  provide  greater  detail  about  the  CFRP  than  appears 
in  the  CFRP  Definition  document,  but  rather  to  make  it  more  accessible  and  relevant  to  software 
engineering  practitioners.  The  scenarios  are  meant  to  show  the  reader  how  it  “feels”  to  apply  the 
CFRP.  They  are  not  intended  to  be  general  prescriptions  or  recipes  for  CFRP  usage.  Although  the 
scenarios  are  concrete,  in  that  they  refer  to  specific  methodologies  and  tools  and  include  planning 
choices,  they  are  not  intended  to  reflect  the  “right”  selections  or  choices  in  general. 

This  section  includes:  (a)  an  overview  of  the  scenarios  that  defines  their  overall  context  and  de¬ 
scribes  their  general  format,  (b)  the  four  scenarios,  and  (c)  a  review  and  analysis  of  the  scenarios 
in  terms  of  how  they  communicate  key  CFRP  concepts. 


3.1  Scenario  Overview 

The  scenarios  in  this  section  illustrate  several  different  ways  in  which  the  CFRP  can  be  applied 
and  reflect  several  different  circumstances  under  which  it  can  be  applied.  The  scenarios  elaborate 
on  some  of  the  CFRP  uses  that  were  discussed  in  Section  2.  Two  scenarios  show  the  use  of  the 
CFRP  to  support  planning,  one  scenario  depicts  the  use  of  the  CFRP  to  support  the  definition  of 
reuse-oriented  application  engineering  processes,  and  one  scenario  Illustrates  the  use«of  the  CFRP 
as  a  mechanism  for  understanding  and  evaluating  an  existing  reuse  plan. 

To  help  establish  a  context  for  the  scenarios,  recall  that  the  CFRP  Definition  document  defines 
a  reuse  program  as  the  set  of  activities  encompassed  by  (and  including)  a  particular  instance  of 
the  Reuse  Management  idiom.  Each  reuse  program  has  a  scope  of  planning  that  includes  a  set 
of  interconnected  reuse  projects  and  infrastructure  activities  operating  in  the  context  of  a  set  of 
selected  domains.  A  reuse  project  is  any  project  (typically  involving  activities  from  one  or  more  of 
the  Reuse  Engineering  process  families)  that  is  enacted  by  Reuse  Enactment  processes.  Figure  3 
shows  the  Plan-Enact-Learn  loop  of  a  reuse  program  and,  within  the  Enact  box,  three  P-E-L  loops 
representing  Asset  Creation,  Management,  and  Utilization  projects.  The  figure  locates  the  four 
scenarios  in  terms  of  planning  level  or  scope  and  in  terms  of  the  CFRP  families  to  which  they 
most  directly  apply.  The  figure  is  not  meant  to  imply  that  the  scenarios  are  all  telling  related 
stories  within  the  same  reuse  program  context;  it  merely  indicates  which  aspects  of  the  CFRP 
each  scenario  is  a.ddressing,  and  at  what  planning  level.  Some  scenarios  include  activity  in  multiple 
families;  in  those  cases  the  location  indicated  is  the  family  where  the  scenario  activity  is  primarily 
focused. 

Scenario  1  suggests  one  way  in  which  the  CFRP  can  be  used  as  a  template  or  model  (a  “yardstick” ) 
for  understanding,  characterizing,  and  evaluating  a  reuse  plan  that  was  developed  outside  the  CFRP 
context.  Figure  1  shows  this  scenario  occurring  in  the  Learn  box  of  the  high  level  P-E-L  loop  (shown 
by  a  circled  1  in  the  figure  pointing  to  that  box).  This  is  because  it  involves  using  the  CFRP  as 
an  instrument  to  evaluate  and  learn  about  other  reuse  plans  and  also  because  it  directly  illustrates 
CFRP  learning  processes. 
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Figure  3:  Scenario  Location 

Scenario  2  illustrates  the  use  of  the  CFRP  in  guiding  the  definition  of  an  application  engineering 
process  that  incorporates  reuse.  It  describes  a  process  engineer  integrating  Asset  Utilization  pro¬ 
cesses  into  an  organization’s  application  engineering  process.  This  scenario’s  location  is  depicted  as 
the  Plan  box  of  the  Asset  Utilization  P-E-L  loop  because  it  focuses  on  detailed  planning  activities 
associated  with  the  definition  of  project  processes  that  incorporate  Asset  Utilization.  Note  that 
it  may  also  be  valid  to  view  this  scenario  as  describing  Infrastructure  Implementation  within  the 
top-level  Enact  box  in  the  figure,  where  the  infrastructure  in  this  case  is  a  process  model  that  will 
be  applicable  to  more  than  one  appUcation  engineering  project  within  the  reuse  program. 

Scenario  3  describes  the  use  of  the  CFRP  for  planning  a  single  project  in  the  context  of  a  higher 
level  reuse  program  plan.  The  project  being  planned  is  an  Asset  Creation  project,  so  the  scenario 
is  located  in  Figure  3  in  the  Plan  box  of  the  Asset  Creation  P-E-L  loop.  This  scenario  involves 
definition  of  a  new  domain  analysis  process  model  that  is  applicable  across  multiple  projects,  so  it  is 
comparable  to  scenario  2  in  that  it  can  also  be  viewed  as  describing  Infrastructure  Implementation 
processes. 

Scenario  4  addresses  the  application  of  the  CFRP  to  the  high  level  planning  of  a  domain-specific 
reuse  program  during  the  preparation  of  a  proposal.  Therefore  it  is  located  in  the  Plan  box  of  the 
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1. 

A  reuse-based  approach  to  software  engineering  should  be  driven  by  well-defined, 
repeatable  processes. 

2. 

Software  reuse  hets  both  management  and  engineering  dimensions,  whose  activities 
are  captured  in  the  CFRP  idioms. 

3. 

CFRP  process  categories  provide  a  definition  of  the  activities  involved  in  a  process- 
driven,  domain-specific  reuse-based  approach  to  software  engineering. 

4. 

Reuse  should  be  applied  as  a  “first  principle”;  that  is,  reusable  products  should 
always  be  considered  as  the  basis  for  work  before  creating  new  products;  experiences, 
processes,  and  workproducts  should  always  be  recorded  for  learning  and  for  possible 
reuse. 

5. 

Measurement,  learning,  and  managed  change  are  essential  and  pervasive  in  reuse. 

6. 

Infrastructure  is  important  to  reuse  and  must  be  designed  to  support  it. 

7. 

A  domain-specific,  architecture-driven  approach  to  reuse  is  important,  from  both 
an  engineering  and  a  management  perspective. 

8. 

The  asset  producer,  broker,  and  consumer  roles  are  distinct  within  Reuse 
Engineering. 

9. 

The  CFRP  is  generic  with  respect  to  domains,  technologies,  management  styles, 
and  economic  sectors. 

10. 

CFRP  processes  should  be  integrated  with  overall  planning  and  engineering 
practices. 

11. 

The  CFRP  is  a  process  modeling  language  with  mechanisms  to  support  composition 
of  complex  process  configurations. 

12. 

The  CFRP  is  scalable  and  applicable  at  different  organizational  levels. 

13. 

The  CFRP  is  a  domain  model  and  high  level  process  architecture  for  the  reuse 
process  domain;  it  provides  a  basis  for  the  analysis  of  reuse  processes  and  the 
definition  of  reusable  process  assets. 

Table  1:  CFRP  Themes 


high  level  P-E-L  loop. 

Each  scenario  presents  a  single  narrative  thread,  describing  a  sequence  of  activities  undertaken  to 
accomplish  some  goal.  In  general,  when  a  decision  is  made  by  an  individual  in  the  scenario,  only 
the  activities  that  result  from  that  decision  are  subsequently  described;  the  activities  that  would 
have  resulted  from  a  different  decision  are  not  discussed.  Because  one  of  the  goals  has  been  to  keep 
the  scenarios  reasonably  concise,  some  logical  activities  along  even  the  single  thread  path  may  be 
omitted. 


Scenario  Themes 

The  CFRP  Definition  document,  in  its  Summary  section,  identifies  a  set  of  central  concepts,  or 
themes,  that  are  inherent  to  the  CFRP.  These  themes  are  summarized  in  Table  1.  Some  of  the 
themes  convey  messages  about  reuse  that  are  contained  in  the  CFRP,  while  other  themes  relate  to 
characteristics  of  the  CFRP  itself.  The  scenarios  are  designed  to  illustrate  these  themes  to  varying 
degrees,  and  the  themes  are  used  as  a  basis  for  analyzing  the  scenarios  in  Section  3.6. 


Scenario  Assumptions 

The  following  assumptions  apply  to  all  the  scenarios: 
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•  The  individuals  performing  the  scenarios  and  the  organizations  of  which  they  are  a  part  are 
in  the  process  of  transitioning  to  a  process-driven,  domain-specific  reuse-based  approach  to 
software  engineering. 

•  The  individuals  performing  the  scenarios  are  familiar  with  the  CFRP  Definition  and  Appli¬ 
cation  documents.  Both  documents  are  implicit  inputs  to  each  scenario. 

•  No  well  defined  and  documented  processes  exist  for  applying  the  CFRP. 


Scenario  Format 

The  scenarios  conform  to  a  common  outline,  as  follows: 


•  Point  of  View  presents  the  viewpoint  of  the  individual  performing  the  scenario  in  CFRP 
terms. 

•  Context  includes  three  subparts  that  establish  the  background  for  understanding  the  sce¬ 
nario: 

-  Setting  identifies  the  individuals  performing  the  scenario,  places  them  within  their 
organization,  and  describes  the  situation  in  which  they  are  operating. 

-  Goal  states  the  end  towards  which  the  activities  in  the  scenario  are  directed. 

-  Assumptions  indicates  any  relevant  assumptions  in  addition  to  the  general  scenario 
assumptions  listed  above. 

•  Inputs  lists  the  inputs  to  the  scenario  activity. 

•  Outputs  lists  the  products  of  the  scenario  activity. 

•  Scenario  Activity  provides  the  narrative  description  that  is  the  heart  of  the  scenario. 

•  Commentary  concludes  the  scenario  with  a  review  of  significant  points,  such  as  how  the 
CFRP  was  applied  in  the  scenario,  how  the  themes  were  carried  through  by  the  individuals, 
or  what  insights  can  be  gained  from  the  scenario. 


Page  14 


30  September  1993 


STARS- VC- A018/002/00 


3.2  Scenario:  Using  the  CFRP  as  a  Yardstick 
Point  of  View 

This  scenario  describes  the  activities  of  a  reuse  advocate  who  has  been  tasked  to  evaluate  a  reuse 
plan  developed  by  another  division  within  her  company. 


Context 


•  Setting 

Jane  is  a  staff  technologist  and  reuse  advocate  in  the  Federal  Systems  Group  (FSG)  of  Acme 
Corporation.  Another  division  in  the  corporation,  Financial  Products  Division  (FPD),  has 
requested  that  Jane  review  and  comment  on  their  latest  draft  plan  to  institutionalize  reuse 
within  their  business  processes.  FPD’s  reuse  implementation  plan  is  in  response  to  a  mandate 
from  Acme  Corporation  headquarters  that  they  adopt  reuse  as  a  strategy  to  increase  their 
productivity.  The  team  (Dan,  Bill,  and  Adam)  that  has  assembled  FPD’s  plan  contacted 
Jane  in  the  hopes  of  having  her  identify  inconsistencies,  ambiguities,  and  deficiencies  in  the 
plan  that  may  have  resulted  from  their  reuse  inexperience.  Jane  has  agreed  to  do  the  review 
as  an  extension  of  her  responsibility  as  a  reuse  advocate. 

•  Goal 

The  goal  of  this  scenario  is  to  review  FPD’s  reuse  implementation  plan  to  evaluate  how  well 
the  plan  implements  and  supports  reuse-based  activities.  The  CFRP,  as  a  domain  model  of 
reuse  processes,  wUl  be  used  to  establish  criteria  for  the  evaluation. 

•  Assumptions 

-  Jane  is  very  familiar  with  both  CFRP  documents.  She  has  applied  the  CFRP  several 
times  to  assist  in  formulating  long  term  reuse  strategies  within  her  own  division  and 
to  review  reuse  implementation  plans  or  business  process  improvement  plans  for  other 
divisions  that  her  organization  supports. 

—  Jane  has  conducted  several  CFRP  orientation  sessions  for  FPD,  one  of  which  Dan,  Bill, 
and  Adam  attended.  She  also  provided  copies  of  the  CFRP  documents  to  FPD. 


Inputs 

The  inputs  include: 


•  FPD’s  Reuse  Implementation  Plan 

•  FPD’s  Business  Planning  and  Strategy  documents 

•  RedLine  Process  Description 
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When  Jane  agreed  to  FPD’s  request,  she  asked  that,  in  addition  to  the  draft  reuse  plan,  they 
send  her  copies  of  their  most  recent  business  plans  and  Acme’s  directive  mandating  that  they 
institutionalize  reuse. 

Jane  plans  to  perform  the  review  using  the  guidance  of  RedLine,  an  adaptable  process  description 
that  Jane’s  division  has  adopted  for  structured  review  of  documents.  RedLine  was  created  to 
integrate  CFRP  reuse  principles  and  general  process  improvement  principles  into  the  standard 
document  review  practices  of  Acme.  A  summary  of  the  steps  in  RedLine  is: 

1.  Identify  and  assemble  needed  material 

2.  Read/Scan  aU  assembled  material 

3.  Define  process  objectives  and  review  criteria 

4.  Analyze  against  criteria 

5.  Write  up  recommendations/results 

6.  Reflect  on  process/products 


Outputs 

The  outputs  include: 

•  Review  Comments  memo,  including  improvement  recommendations 

•  Process  metrics 

•  Product  metrics 


As  she  has  done  with  previous  reviews  of  reuse  plans,  Jane  intends  to  produce  a  memo  detailing 
her  review  comments,  which  will  include  selected  pieces  of  the  working  material  she  produces. 
In  addition  to  specific  recommended  changes  to  the  draft  plan,  other  candidate  items  to  include 
are:  a  classification  of  the  activities  in  the  plan  in  terms  of  the  CFRP  process  idioms,  families, 
and  categories;  and  diagrams  showing  the  producer  (asset  creato'),  broker  (asset  manager),  and 
consumer  (asset  utilizer)  relationships  found  in  the  plan. 

RedLine  recommends  the  definition  and  collection  ol  metrics  both  for  tracking  process  improvement 
and  productivity  and  for  predicting  resource  and  duration  estimates  in  subsequent  uses  of  RedLine. 
This  prediction  feature  results  from  treating  process  historical  data  as  a  reusable  asset.  Thus,  it  can 
be  assumed  that  throughout  the  scenario  Jane  collects  measures  such  as  page  counts,  material  type 
(document,  memo,  diagram),  and  effort  expended  as  she  completes  each  RedLine  step.  Further,  it 
can  be  assumed  that  Jane  adds  this  data  to  her  personal  process  asset  library,  where  she  manages 
process  descriptions  and  history. 
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Scenario  Activity 

Jane  starts  by  briefly  reviewing  the  RedLine  process  description  and  notes  the  influence  that  the 
CFRP  has  had  on  the  process,  as  reflected  by  its  emphasis  on  the  following: 


•  basing  planned  activity  on  previous  experience 

•  using  previously  created  material  where  possible 

•  reflecting  at  the  end  of  each  task  on  the  reusability  of  newly  created  material 

•  reflecting  at  the  end  of  each  task  or  activity  on  improvements  to  the  process  and  products 

As  a  result,  Jane  realizes  that  this  reuse  plan  review  will  not  only  use  the  CFRf‘  as  a  basis  for 
evaluating  the  plan,  but  will  itself  embody  the  CFRP  in  many  ways  through  appliratmn  of  the 
RedLine  process.  With  this  in  mind,  Jane  begins  the  process. 

Step  1:  Identify  and  Assemble  Needed  Material 

As  a  first  step,  Jane  identifies  the  business  strategy  documents,  the  CFRP  dorum^nik.  and  the 
reuse  plan  to  be  reviewed,  and  collects  all  this  material  at  her  desk. 

Step  2:  Read/ Scan  All  Assembled  Material 

Next,  the  RedLine  process  recommends  reading  all  the  material  that  is  new  and  re- reading  any 
additional  material  that  may  provide  a  basis  for  the  review  criteria.  The  process  suggests  marking 
aU  passages  that  should  be  revisited  in  more  depth  later. 

Jane  decides  to  start  by  reading  the  RedLine  process  description  once  all  the  way  through  before 
reading  the  other  documents.  She  has  used  RedLine  before,  so  re-reading  the  process  description 
gives  her  an  opportunity  to  improve  her  understanding  of  the  process. 

Next,  Jane  reads  through  the  CFRP  documents.  Since  she  is  planning  to  carefully  analyze  the 
process  diagrams  in  the  FPD  plan,  she  spends  most  of  her  CFRP  review  time  inspecting  the 
following  diagrams  that  describe  information  flows  within  and  among  the  CFRP  process  families: 


•  CFRP  Definition  document: 

—  The  diagram  in  the  Section  3  introduction  that  depicts  the  entire  CFRP  with  its  overall 
inputs  and  outputs  and  shows  the  general  paths  of  information  flow  among  the  families. 

—  The  diagrams  within  the  individual  process  family  description  sections  that  show  the 
inputs  and  outputs  for  each  family. 

-  The  diagrams  in  Appendix  A  that  show  various  potential  information  flows  and  in¬ 
terrelationships  among  organizations  or  workgroups  having  different  responsibilities  for 
reuse- based  development. 

•  CFRP  Application  document: 

-  The  dia.gTa.Tn  in  Section  2  that  shows  high-level  information  flows  among  activities  in  a 
“dual  life-cycle”  process  model. 
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-  The  IDEFo  diagrams  in  Appendix  A  that  show  one  interpretation  of  the  information 
flows  among  the  categories  within  each  family. 


After  reading  the  CFRP  documents,  Jane  scans  the  FPD  reuse  implementation  plan  and  business 
strategy-  material.  While  she  reads,  she  adds  indexing  markers  to  the  passages  that  she  believes 
will  be  most  relevant  to  her  evaluation. 

Step  S:  Define  Process  Objectives  and  Review  Criteria 

Jane  is  now  ready  to  define  the  “process  objectives”  (i.e.,  the  objectives  that  will  be  used  to  evaluate 
how  weU  the  RedLine  process  is  performed)  and  the  detailed  “review  criteria”  (i.e.,  the  particular 
measures  or  standards  against  which  the  reuse  plan  will  be  evaluated  during  the  RedLine  process). 

RedLine  recommends  that  the  process  objectives  be  expressed  in  terms  of  quantifiable  quality 
measures  that  the  review  output  must  meet  or  exceed.  Jane  looks  over  the  recommendations  that 
she  made  to  herself  the  last  time  she  applied  RedLine  and  decides  to  reuse  two  of  them  as  the 
process  objectives: 

1.  All  conclusions  are  backed  up  with  citations  to  relevant  portions  of  the  CFRP  or  relevant 
Acme  policy  and  strategy  documents. 

2.  There  is  at  least  one  comment  per  numbered  section,  figure,  or  table  in  the  plan. 

Jane  next  identifies  the  review  criteria  for  FPD’s  plaa.  Jane  writes  down  several  criteria  that  pertain 
to  FPD’s  business  planning,  and  also  indicates  several  aspects  of  the  CFRP  that  will  be  used  as 
criteria.  For  example,  she  expects  the  reuse  plan  to  include  one  or  more  elements  corresponding  to 
each  of  the  CFRP  process  families,  or  to  at  least  include  rationale  for  why  such  elements  are  missing. 
Although  Jane  does  not  believe  that  every  reuse  plan  should  incorporate  elements  corresponding 
to  each  CFRP  process  family,  she  does  believe  that  until  reuse  has  become  institutionalized  within 
her  company,  each  plan  should  provide  evidence  that  the  appropriateness  or  utility  of  each  process 
family  has  been  considered. 

Step  4:  Analyze  Against  Criteria 

The  heart  of  the  RedLine  process  is  to  analyze  the  plan  relative  to  the  defined  criteria.  RedLine  here 
offers  general  guidelines  for  evaluating  consistency,  clarity,  and  completeness,  which  Jane  knows  are 
intended  to  be  adapted  to  the  specific  type  of  material  being  reviewed.  As  a  basis  for  this  analysis, 
Jane  turns  to  the  CFRP  documents,  as  she  planned,  and  focuses  particularly  on  the  diagrams  that 
describe  CFRP  information  flows,  which  she  had  examined  in  step  2  above. 

In  further  studying  these  CFRP  diagrams,  Jane  recalls  that  the  reuse  implementation  plan  under 
review  contains  a  diagram  entitled  “Revised  FPD  Software  Business  Process”.  This  diagram  {as 
annotate  '  ''y  Jane)  is  included  in  Figure  4.  Jane  proceeds  to  classify  each  process  box  in  the 
diagram  in  terms  of  the  CFRP  families  and  categories;  her  final  classification  is  shown  at  the 
bottom  of  the  figure.  Jane  bases  her  classification  on  the  titles  in  the  boxes,  the  description  of  each 
box  in  the  plan’s  text,  and  the  flows  shown  in  the  diagram. 

In  performing  the  classification,  Jane  initially  classifies  each  box  in  terms  of  the  one  or  more 
CFRP  families  to  which  it  most  clearly  maps.  Jane  finds  that  such  classification  is  not  always 
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domain  model  of  the  requirements  for  the  business  area.  She  also  hnds  that  the  planning  aspects  of 
processes  G  and  I  are  not  described  in  enough  detail  to  enable  classification  in  specific  categories. 
In  general,  Jane  finds  that  no  Reuse  Planning  categories  and  few  Reuse  Learning  categories  are 
described  explicitly  in  the  text. 

Jane  then  compares  the  information  flows  in  the  diagram  to  the  flows  in  the  STARS  CFRP  diagrams, 
both  to  assess  the  validity  of  the  flows  and  to  identify  specific  Create-Manage-Utilize  (C-M-U)  and 
Plan- Enact- Learn  (P-E-L)  idioms.  Since  the  flows  are  unlabeled,  Jane  makes  some  assumptions 
about  their  nature  based  on  supporting  information  she  finds  in  the  text.  One  of  the  conclusions 
she  reaches  is  that  although  one  FPD  business  objective  is  to  buy  as  many  off-the-shelf  components 
as  possible,  no  flow  of  such  components  is  shown  in  the  diagram  nor  is  any  mentioned  in  the  text. 

Jane  also  notices  that  process  F  does  not  include  any  analysis  of  the  generic  architecture  to  help 
establish  requirements.  Jane  believes  this  is  an  important  aspect  of  domain-specific  reuse-based 
software  engineering,  so  she  formulates  a  recommendation  that  the  process  be  changed  to  include 
such  an  analysis. 

On  a  positive  note,  the  generic  architecture  and  existing  components  in  the  reuse  library  are  inputs 
to  the  development  of  the  rapid  prototype  plan  (process  G).  She  assumes  that,  since  the  rapid 
prototype  is  an  input  to  the  development  of  the  operational  implementation  plan  (process  I),  the 
operational  system  is  also  developed  using  the  generic  architecture  and  components. 

As  a  result  of  her  analysis,  Jane  finds  two  distinct  C-M-U  idioms  ([A,  B,  D,  E,  G,  H]  and  [A,  B, 
D,  E,  I,  J])  and  no  complete  P-E-L  idioms.  The  first  C-M-U  idiom  produces  rapid  prototypes;  the 
second  produces  operational  systems.  Jane  finds  that  the  feedback  flows  needed  to  ‘‘close  the  loop” 
for  potential  P-E-L  idioms  are  incomplete.  In  particular,  there  is  no  direct  feedback  from  process  J 
to  process  A,  although  there  is  feedback  from  process  I  (the  planning  and  early  utilization  activity). 
In  addition,  there  are  no  specific  activities  identified  to  learn  from  the  feedback.  In  other  words, 
processes  I  and  J  provide  the  Plan  and  Enact  parts  of  a  P-E-L  idiom,  but  the  Learn  part  is  at  best 
only  vaguely  specified. 

Jane  decides  to  consult  the  text  in  more  detail  to  see  if  it  describes  any  P-E-L  idioms  that  are 
not  apparent  in  the  diagram.  She  finds  that  the  individuals  responsible  for  planning  are  identified, 
but  the  process  steps  for  planning  are  not  discussed  in  any  detail,  and  no  metrics  are  identified. 
She  also  verifies  her  earlier  concern  that,  although  feedback  appears  on  the  diagrams,  there  are  no 
explicit  activities  to  respond  to  it.  There  is  only  one  activity  (the  technology  exploration  activity 
identified  above)  that  explicitly  addresses  learning  in  any  form.  Jane  writes  a  recommendation  that 
the  next  draft  of  FPD’s  plan  specifically  address  these  issues. 

Step  5:  Write  Up  Recommendations  and  Results 

Jane  next  must  package  her  recommendations,  conclusions,  and  observations  into  their  final  form 
and  send  them  to  the  authors  of  the  plan.  RedLine  recommends  that  a  summary  be  produced  that 
highlights  the  major  conclusions  of  the  review,  with  the  detailed  comments  and  supporting  material 
packaged  separately.  While  she  is  packaging  her  results  in  this  format,  Jane  notices  that  some  of 
her  comments  are  really  questions  that  she  would  want  to  consider  about  any  reuse  implementation 
plan,  so  she  collects  and  saves  these  questions  separately. 

After  she  has  completed  the  paurkaging,  she  sends  the  material  to  Dan,  BiU,  and  Adam  in  both 
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hardcopy  and  electronic  form  and  notifies  them  that  the  review  is  completed. 

Step  6:  Reflect  on  Process  and  Products 

The  final  step  in  the  RedLine  process  was  specifically  designed  to  incorporate  the  notion  of  Reuse 
Learning  and  to  increase  productivity  by  encouraging  retention  of  reusable  material.  The  step 
describes  a  reflective  activity  in  which  Jane  is  to: 

•  identify  material  she  produced  that  should  be  saved  for  later  use 

•  evaluate  her  use  of  RedLine  relative  to  the  process  objectives  she  defined  in  Step  3 

•  suggest  candidate  RedLine  process  improvements  or  clarifications 

Jane  places  into  her  personal  process  asset  library  the  set  of  questions  she  compiled  during  her 
review  and  the  measures  of  effort  she  collected  about  different  types  of  reviewed  material  (pages  of 
text,  diagrams,  tables,  etc.). 

Next,  Jane  evaluates  her  review  against  the  first  process  objective  (i.e.,  supporting  conclusions  with 
citations  to  relevant  material).  She  finds  this  activity  tedious  because  she  embedded  the  citations 
in  the  text  of  each  conclusion  or  recommendation  and  discovers  that  she  missed  entering  some  of 
them.  She  makes  a  note  in  her  copy  of  RedLine  to  put  citations  at  the  end  of  each  conclusion  or 
recommendation  in  the  future.  She  also  notes  that  she  should  reuse  this  process  objective  the  next 
time  she  uses  RedLine. 

Jane  then  evaluates  her  review  against  the  second  process  objective  (i.e.,  including  at  least  one 
comment  per  major  element  of  the  plan).  She  concludes  that  the  method  she  used  for  organizing 
the  comments  was  effective  (she  used  an  outline  of  the  FPD  plan).  She  notes  that  she  should  reuse 
this  method  in  the  future  and  then  places  all  her  notes  about  this  application  of  RedLine  into  her 
personal  process  asset  library. 

Jane’s  last  action  is  to  send  a  message  to  her  organization’s  electronic  mailbox  for  RedLine  feedback. 
The  message  suggests  that  the  use  of  an  outline  to  organize  the  detailed  review  comments  should 
be  added  to  the  process  heuristics.  * 


Commentary 

In  this  scenario  we  have  seen  Jane  following  P-El-L  idioms  in  her  day-to-day  work.  That  is,  for  Jane, 
reuse  and  learning  have  become  a  natural  part  of  the  way  she  carries  out  her  responsibilities  and 
improves  her  productivity.  We  have  also  seen  how  reuse  and  learning  can  fit  into  a  general  engi¬ 
neering  practice,  as  evidenced  by  Jane’s  use  of  the  RedLine  process  that  has  been  institutionalized 
in  her  division. 

In  addition,  we  have  seen  Jane  perform  several  analyses  in  evaluating  the  completeness  and  con¬ 
sistency  of  a  reuse  implementation  plan,  based  on  using  the  CFRP  as  a  domain  model  of  reuse 
processes.  The  analyses  performed  were  to: 

•  compare  the  names  of  activities  and  processes  to  CFRP  family  and  category  names; 
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•  compare  the  text  descriptions  of  activities  and  processes  to  the  descriptions  of  CFRP  families 
and  categories; 

•  compare  the  asset  flows  in  and  out  of  processes  against  the  flows  shown  in  the  CFRP  diagrams; 

•  classify  the  sequencing  of  activities  and  processes  in  terms  of  CFRP  idioms,  families,  and 
categories. 


Readers  concerned  with  technology  support  issues  should  note  that,  except  for  the  explicit  use  of 
electronic  mail,  no  specific  support  technologies  were  identified  in  this  scenario.  The  activities  could 
have  been  highly  automated  or  could  have  used  paper  and  pencil.  For  example,  Jane’s  personal 
process  asset  library  could  have  been  a  bookshelf  and  a  box  of  file  cards,  the  indexing  markers  could 
have  been  “sticky  notes”,  and  the  diagram  could  have  been  created  by  annotating  a  photocopy. 
On  the  other  hand,  CASE  tools  and  an  automated  asset  library  mechanism  would  make  Jane’s  job 
easier. 
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3.3  Scenario:  Using  the  CFRP  to  Define  an  Application  Engineering  Process 
Point  of  View 

This  scenario  describes  the  activities  of  a  process  engineer  responsible  for  developing  a  reuse-driven 
application  engineering  process. 


Context 


•  Setting 

The  Measurement  Systems  Applications  (MSA)  organization  is  the  primary  R&D  group 
within  Metrotek  Corporation,  a  company  that  produces  software  applications  that  control 
and  monitor  diverse  measurement  instruments.  MSA  is  organized  principally  by  develop¬ 
ment  program.  Each  program  includes  a  set  of  projects  that  produce  applications  within  a 
particular  application  area.  Pat  Mabutu  manages  the  Radio  Signal  Analysis  (RSA)  program. 
Kim  Lee  manages  the  Communications  Interception  (Cl)  program. 

MSA  also  includes  a  number  of  groups  that  provide  services  to  development  programs  and 
projects  in  the  organization.  These  groups  are  managed  centrally  in  a  single  department. 
They  include  Software  Maintenance,  Quality  Assurance,  and  Process  Improvement.  Chris 
Mendoza  is  the  senior  process  engineer  for  the  Process  Improvement  group.  Jan  Swenson 
manages  the  Software  Maintenance  group. 

MSA  has  traditionally  relied  on  software  leverage  (reusing  substantial  portions  of  previous 
applications,  generally  without  prior  planning)  as  well  as  other  forms  of  ad  hoc  reuse  in 
developing  new  applications.  Metrotek  management  has  asked  MSA  to  move  toward  black¬ 
box  reuse  as  a  means  of  meeting  business  objectives  for  time-to-market  and  quality. 

•  Goal 

Chris  has  been  given  responsibility  to  define  a  reuse-based  application  engineering  (A£)  pro- 
-  cess  via  incremental  changes  to  the  existing  MSA  AE  process,  using  the  CFRP  Definition 
document  for  guidance. 

•  Assumptions 

—  The  MSA  organization  is  process-aware,  with  active  Total  Quality  Management  and 
Continuous  Process  Improvement  programs  in  place. 

-  MSA  upper  management  is  committed  to  moving  from  ad  hoc  software  leverage  to¬ 
wards  establishment  of  centrally-managed  asset  bases  to  avoid  maintenance  redundancy. 
However,  no  significant  changes  have  yet  been  made  to  implement  this  strategy. 

—  MSA  has  a  stable  set  of  domains  based  on  well-defined  lines  of  business. 

—  Chris  has  recently  attended  a  one-day  CFRP  orientation  presented  to  the  Process  Im¬ 
provement  group  by  an  outside  consultant.  He  thus  has  significant  knowledge  of  CFRP 
concepts,  but  no  practical  experience  in  applying  the  CFRP. 
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Inputs 


•  The  existing  MSA  AE  process  that  dehnes,  in  abstract  terms,  the  activities  and  interrelation¬ 
ships  involved  in  application  engineering  within  MSA. 

•  The  existing  MSA  life  cycle  document  that  defines  the  life  cycle  that  is  followed  in  developing 
and  evolving  products  within  MSA.  This  document  is  consistent  with  the  MSA  AE  process, 
but  specializes  it  by  imposing  specific  temporal  sequencing,  checkpoints,  and  milestones. 

•  Experience  reports  and  lessons  learned  from  projects  that  have  applied  the  MSA  life  cycle 
document. 

•  Up-to-date  copies  of  business  objectives,  strategy  documents,  and  drafts  of  product  plans  for 
the  RSA  and  Cl  programs. 

•  The  MSA  Process  Modification  Plan  that  defines  how  processes  are  evolved  within  the  orga¬ 
nization.  The  plan,  based  on  the  organization’s  Continuous  Process  Improvement  approach, 
ensures  that  aU  affected  parties  are  consulted  throughout  the  modification  effort,  that  impact 
on  existing  activities  is  analyzed,  and  so  on. 


Outputs 


•  The  target  MSA  reuse-based  AE  process  (with  supporting  documentation)  that  satisfies 
Chris’s  objectives  and  constraints. 

•  A  document  that  describes  how  the  existing  MSA  AE  process  will  evolve  toward  the  target 
MSA  reuse-based  AE  process.  The  document,  based  on  the  Process  Modification  Plan,  defines 
the  objectives  for  each  cycle  of  transition  towards  the  new  process  and  describes  the  sequence 
and  timing  for  the  introduction  of  process  changes. 

•  A  life  cycle  document  describing  the  product  life  cycle  for  next  generation  projects  within  the 
RSA  and  Cl  programs,  based  on  an  expected  transition  to  the  MSA  reuse-based  AE  process. 


Scenario  Activity 

Chris’s  recent  CFRP  orientation  has  given  him  confidence  that  the  correct  approach  in  trying 
to  incorporate  reuse  into  the  MSA  AE  process  is  to  make  it  more  consistent  with  the  CFRP. 
To  gain  better  insight  into  how  this  can  best  be  audiieved,  Chris  begins  by  reviewing  the  CFRP 
Definition  and  Application  documents  in  detail.  Chris  decides  to  take  a  very  methodical  approach 
to  applying  the  CFRP,  and  focuses  initially  on  identifying  the  CFRP  process  elements  that  seem 
most  appropriate  to  incorporate  into  the  MSA  AE  process.  He  quickly  determines  that  the  Reuse 
Engineering  idiom  applies  most  directly  to  the  task,  although  concepts  from  the  Reuse  Management 
idiom  wiU  influence  the  work  as  well. 

After  studying  the  Reuse  Engineering  idiom  in  detail,  Chris  decides  that  he  will  not  try  to  define 
a  complete  set  of  Create- Manage- Utilize  processes  at  this  time.  Chris  knows,  from  reflecting  on 
the  implications  of  the  CFRP,  that  Asset  Management  will  have  to  be  addressed  explicitly  at  some 
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point  as  demands  for  asset  support  increase.  However,  he  assumes  for  now  that  Asset  Management 
will  be  performed  by  an  existing  MSA  group,  using  mostly  existing  processes.  Similarly,  Asset 
Creation  will  have  to  be  addressed  when  consumers  identify  asset  needs  that  cannot  be  met  with 
the  existing  asset  base.  However,  investment  in  Asset  Creation  efforts  will  be  difficult  to  justify 
at  this  early  stage,  and  it  is  generally  assumed  that  MSA’s  initial  move  to  reuse  will  be  based  on 
reuse  and/or  reengineering  of  existing  application  artifacts.  From  this  analysis,  it  is  clear  to  Chris 
that  his  process  modification  effort  should  initially  focus  on  incorporating  CFRP  Asset  Utilization 
processes  into  the  MSA  AE  process.  Chris  notes  the  risk  of  starting  with  Asset  Utilization  without 
explicitly  addressing  other  reuse  processes  and  their  implications.  He  hopes  that  identifying  such 
issues  to  MSA  management  will  result  in  planning  for  the  development  of  other  reuse  processes  in 
the  near  future. 

Looking  at  the  Existing  Organization  and  Infrastructure 

Chris’s  next  step  is  to  assess  the  current  MSA  organization  and  its  existing  infrastructure  to  es¬ 
tablish  sufficient  context  for  modifying  the  AE  process.  Chris  draws  upon  his  own  knowledge  of 
the  MSA  organization  and  conducts  interviews  to  gain  additional  information  that  enables  him  to 
map  the  organization  to  the  CFRP  idioms  and  families.  This  process  reinforces  many  of  his  initial 
conclusions.  There  is  no  formal  Asset  Creation  group,  although  application  engineering  projects 
produce  some  artifacts  that  support  limited  reuse.  The  few  CFRP  Asset  Management  activities 
discernible  within  MSA  are  performed  almost  exclusively  by  the  Maintenance  group,  and  Chris 
learns  that  this  group  will  be  assigned  general  Asset  Management  responsibility,  using  the  existing 
maintenance  process.  Chris  identifies  all  of  the  application  engineering  projects  as  asset  utilizers, 
but  he  notes  that  some  processes  in  the  Asset  Utilization  family,  particularly  Asset  Tailoring,  may 
be  split  between  the  AE  projects  and  the  Maintenance  group  (in  its  Asset  Management  role). 

Because  Chris’s  process  modification  task  must  deal  with  the  real  constraints  of  the  MSA  orga¬ 
nization,  Chris  examines  the  existing  infrastructure  to  assess  how  well  it  could,  with  little  or  no 
modification,  support  reuse-baised  processes.  MSA’s  application  projects  adreaidy  use  a  software 
development  environment  that  includes  a  number  of  sophisticated  development  tools  and  strongly 
enforces  configuration  management  policies.  MSA  haus  a  strong  training  program,  but  it  does  not 
currently  include  any  training  that  is  explicitly  reuse-oriented.  The  MSA  engineering  staff  has  no 
significant  experience  or  expertise  in  managed  reuse,  but  has  a  generally  high  level  of  technical  com¬ 
petence.  Overall,  Chris  sees  some  potential  for  adapting  the  infrastructure  to  support  reuse,  but 
decides  to  postpone  recommending  specific  changes  until  he  begins  defining  a  plan  for  incremental 
adoption  of  the  target  MSA  reuse-based  AE  process. 

Pat,  Kim,  and  Jan  brief  Chris  on  existing  assets  that  might  be  placed  in  an  asset  library.  Their 
conclusion  is  that  the  library  will  be  initially  populated  with  designs,  code,  tests,  and  usage  doc¬ 
umentation  for  about  twenty  large  (1  KSLOC  -  20  KSLOC),  functionally-distinct  components, 
and  therefore  shorild  not  be  very  complex.  Chris  adds  the  information  on  these  assets  to  the  data 
dictionary  he  has  begun  to  develop  for  the  MSA  reuse-based  AE  process.  Utilization  of  specific 
classes  of  assets  will  be  explicitly  addressed  in  the  process,  and  terminology  associated  with  those 
classes  of  assets  will  thus  appear  in  the  names  of  activities  and  data  flows. 

Chris  notes  that  MSA  has  no  existing  reuse  funding  model  and  lacks  appropriate  incentives  and 
rewards  for  managers  and  application  engineers.  The  organization  map  Chris  built  earlier  helps 
him  identify  the  people  who  would  need  to  sponsor  changes  in  these  policy  areas.  Chris  concludes 
that  MSA’s  director,  T.  J.  Harris,  must  be  educated  about  both  funding  and  personnel  issues. 
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Chris  adds  this  to  a  list  of  issues  that  are  external  to  the  current  process  modeling  effort  but  may 
eventually  impact  the  overall  MSA  reuse  program. 

Comparing  the  Existing  Process  with  the  CFRP 

Chris  begins  the  development  of  the  MSA  reuse-based  AE  process  by  inspecting  both  the  existing 
MSA  AE  process  and  the  MSA  life  cycle  document  that  is  a  concrete  embodiment  of  the  process. 
The  ultimate  target  of  Chris’s  work  is  a  modified  life  cycle  document  that  reflects  his  modified  AE 
process,  because  that  document  will  be  the  instrument  that  directly  impacts  the  day-to-day  work 
of  application  engineers  in  the  future.  During  this  activity,  Chris  consults  the  CFRP  Definition 
document  and  highlights  passages  from  the  Asset  Utilization  section  that  are  clearly  relevant  to 
evolving  the  current  process. 

Because  the  existing  MSA  AE  process  is  organized  as  activities  that  each  produce  distinct  kinds  of 
life  cycle  products  (e.g.,  requirements,  designs,  code,  test  cases,  usage  documentation ).  Chris  quickly 
discerns  that  the  CFRP  Asset  Utilization  processes  will  play  a  role  in  each  of  the  AF  activities  (e.g., 
analyze,  design,  implement,  test).  This  will  require  a  methodical  approach  to  integrating  the  CFRP 
with  the  MSA  AE  process.  Chris  expects  that  the  revised,  reuse-based  AE  life  cycle  activities  will 
be  adopted  at  different  times,  reflecting  phased  adoption  of  the  reuse  of  different  life  cvi  le  products. 
However,  he  is  not  yet  prepared  to  predict  the  exact  order  in  which  they  will  be  adopted,  so  he 
decides  to  integrate  the  Asset  Utilization  processes  with  aU  the  AE  activities  and  defer  definition 
of  an  incremental  adoption  strategy  until  later.  Chris  decides  to  approach  the  pro<e«»  integration 
problem  by  looking  at  each  CFRP  Asset  Utilization  process  category  and  considering  its  role  in 
each  of  the  MSA  AE  activities. 

Integrating  CFRP  Asset  Criteria  Determination 

After  reviewing  the  Asset  Criteria  Determination  process  category,  Chris  identifies  the  need  for 
guidelines  to  help  engineers  define  appropriate  asset  criteria  and  separate  the  criteria  into  the 
“shallow”  criteria  used  in  Asset  Identification  and  the  “deep”  criteria  used  in  Asset  Selection.  He 
decides  that  there  should  be  a  separate  guideline  document  for  each  life  cycle  product,  and  each  of 
these  documents  should  be  partitioned  into  guidelines  for  defining  shallow  and  deep  criteria.  Chris 
authors  an  initial  set  of  guideline  documents,  which  include  organization-independent,  domain- 
independent  examples  of  criteria,  based  on  inputs  from  Pat  and  Kim’s  application  projects.  The 
guidelines  initially  include  Asset  Identification  criteria  examples  such  as  “Code  must  be  written 
in  ANSI  Standard  C”  and  “Defect  density  in  code  must  be  less  than  0.1  defect /KSLOC”.  Asset 
selection  criteria  examples  include  “Asset  usage  documentation  must  reflect  the  current  state  of 
the  code”  and  “Design  assets  must  specify  interfaces  consistent  with  the  application  architecture”. 
Chris  is  careful  to  state  in  the  guidelines  that  the  included  criteria  are  only  examples,  and  actual 
criteria  will  be  derived  from  characteristics  of  the  asset  base,  the  application  requirements,  and 
other  factors.  To  make  this  point  clear,  he  also  authors  a  draft  document  that  articulates  an  initial 
set  of  general  principles  for  deriving  shallow  and  deep  criteria,  based  on  context. 

Integrating  CFRP  Asset  Identification 

MSA’s  existing  AE  process  does  not  cover  identification  of  existing  software  assets,  but  does  define 
a  method  for  requesting  electronic  copies  of  marketing  and  technical  reports,  planning  documents, 
and  measurement  systems  applications  information.  Chris  extends  this  method  to  define  a  way  of 
applying  Asset  Identification  criteria  to  these  information  sources  to  find  potential  external  assets 
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for  use  in  an  application  engineering  effort.  In  addition,  Chris  establishes  a  process  for  applying 
the  Asset  Identification  criteria  to  the  established  in-house  asset  base  to  identify  internal  assets 
that  are  relevant  to  the  application.  Chris  ensures  that  both  of  the  techniques  he  has  defined  are 
applicable  to  aU  life  cycle  products. 

Integrating  CFRP  Asset  Selection 

Considering  the  kind  of  asset  library  that  Chris  believes  MSA  is  likely  to  establish  (domain-specific 
and  architecture-based,  with  large-grained,  complementary  assets),  he  initially  sees  no  need  for  a 
sophisticated  Asset  Selection  process.  After  consulting  the  CFRP  Definition  document,  however,  he 
recognizes  that  the  Asset  Selection  activities  focus  on  in-depth  evaluation  of  identified  assets  and  can 
be  rather  extensive.  He  also  realizes  that,  since  the  Asset  Identification  process  he  has  developed 
wiU  identify  assets  external  to  the  organization,  the  Asset  Selection  process  must  accommodate 
assets  beyond  the  relatively  limited  scope  of  the  internal  asset  library.  Chris  ultimately  models  the 
Asset  Selection  process  to  emphasize  select /reject  decisions  based  on  in-depth  analysis  of  assets 
addressing  each  of  the  MSA  AE  life  cycle  activities,  driven  by  the  Asset  Selection  criteria. 

While  modeling  the  process,  Chris  considers  Asset  Management  and  infrastructure  issues  associ¬ 
ated  with  Asset  Selection.  In  addition  to  an  asset  library  mechanism,  technology  support  for  Asset 
Selection  could  include:  tools  for  understanding  requirements,  design,  and  code;  document  proces¬ 
sors  and  hypertext  tools;  and  test  harnesses  and  test  suites.  Chris  also  recognizes  the  importance 
of  asset  consultation  services  to  guide  users  in  the  selection,  and  ultimately  the  reuse,  of  particular 
assets.  Chris  makes  a  note  to  address  these  issues  in  his  incremental  adoption  plan. 

As  indicated  in  the  CFRP  Definition  document,  the  MSA  reuse-based  AE  process  will  need  to 
address  situations  in  which  no  asset  fully  satisfies  the  selection  criteria.  Chris  asserts  that  the  MSA 
reuse-based  AE  process  should  be  an  asset-centered  process,  in  which  engineers  are  encouraged  to 
consider  modifying  their  application  requirements  or  designs  when  they  aren’t  consistent  with  the 
asset  base.  However,  he  realizes  that  such  an  approach  will  be  a  major  change  in  the  application 
engineering  process  and  will  require  a  change  in  mindset  that  most  engineers  (and,  for  that  matter, 
their  managers)  will  find  difficult  to  adopt.  Chris  meets  with  the  management  team  to  discuss 
this  approach  and  draws  analogies  to  the  MSA  hardware  organization’s  practice  of  driving  designs 
from  preferred  parts.  The  managers  follow  the  analogy  and  approve  Chris’s  proposal  to  prescribe 
an  Asset  Selection  process  that  includes  feedback  to  modify  asset  criteria,  if  appropriate,  or  to 
modify  application  system  requirements  or  designs  to  use  available  assets.  Chris  captures  this  in 
the  MSA  reuse-based  AE  process,  then  composes  a  memo  to  the  training  organization  describing 
requirements  for  a  training  package  that  could  reduce  engineer  and  project  manager  resistance  to 
asset-centered  application  engineering.  Chris  has  learned  in  a  perusal  of  reuse  literature  that  a 
policy  of  design  inspections  has  been  an  effective  mechanism  to  ensure  applications  are  designed  to 
reuse  available  assets,  so  this  example  is  provided  in  the  memo. 

Integrating  CFRP  Asset  Tailoring 

One  of  the  few  serious  constraints  that  has  been  imposed  on  Chris  in  defining  the  reuse-based  AE 
process  is  the  requirement  that  application  engineers  be  prevented  from  controlling  modifications 
to  assets.  This  requirement,  levied  by  MSA  senior  management,  is  intended  to  centralize  asset 
modification  responsibility  within  the  Maintenance  group.  Chris  recognizes  that  this  management 
dictum  strongly  impacts  the  Asset  Tailoring  process.  From  the  CFRP  Definition  document,  Chris 
identifies  two  kinds  of  tailoring:  (1)  anticipated  tailoring,  in  which  the  asset  is  designed  to  be 
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adaptable  without  the  asset  itself  being  modified  (e.g.,  application  generators,  build-time  adaptation 
via  configuration  parameters);  and  (2)  unanticipated  tailoring,  in  which  the  asset  is  likely  to  require 
modification  (e.g.,  defect  removal  or  function  enhancement)  to  achieve  the  desired  behavior.  As 
with  the  other  Asset  Utilization  processes  already  considered.  Asset  Tailoring  can  occur  in  each 
activity  in  the  MSA  application  engineering  process. 

Chris  schedules  a  meeting  with  Jan’s  Maintenance  group  and  with  one  of  the  key  senior  managers 
to  resolve  whether  or  not  Jan’s  group  will  control  all  unanticipated  tailoring  that  requires  internal 
modifications  to  assets.  A  compromise  is  reached  that  allows  such  tailoring  to  be  performed  by 
application  engineers  under  some  circumstances.  Each  needed  modification  will  be  reviewed,  and 
those  judged  to  have  no  persistent  value  outside  the  application  for  which  the  modification  is 
needed  will  be  performed  by  application  engineers  and  not  fed  back  to  the  asset  base.  All  other 
modifications  will  be  performed  by  the  Maintenance  group  to  evolve  and  enrich  the  asset  base  over 
time. 

After  further  consideration,  Chris  sees  that  there  are  problems  with  this  approach.  The  AE  process 
must  include  analysis  that  identifies  a  need  for  asset  modification,  must  include  the  request  for 
modification,  and  must  then  include  review  and  implementation  of  the  requested  modification. 
Chris  is  uncertain  how  to  handle  the  situation  in  which  Jan’s  organization  can’t  review  or  implement 
a  requested  modification  in  time  to  avoid  severely  impacting  an  application’s  schedule.  Who  in  the 
organization  should  decide  about  priorities  in  such  matters?  Chris  notes  that  this  kind  of  difficult 
issue  needs  to  be  resolved  among  the  concerned  parties  themselves,  who  will  be  tasked  with  defining 
a  clear  protocol.  The  document  defining  that  protocol  will  be  maintained  in  conjunction  with  the 
MSA  reuse-based  AE  process. 

Integrating  CFRP  Asset  Integration 

Chris  decides  to  request  consultation  from  a  senior  technical  designer,  Sandy  O’Grady,  on  Asset 
Integration  issues.  Chris  specifically  asks  Sandy  to  author  a  document  addressing  Asset  Integration 
in  the  context  of  the  technology  used  in  MSA,  both  currently  and  as  projected  over  the  next  five 
years.  Sandy  looks  at  reusable  document,  design,  and  code  assets  and  assesses  them  relative  to  the 
current  and  future  environments  in  which  their  reuse  is  anticipated.  The  build  tools  for  each  type 
of  asset  are  also  studied.  In  some  cases,  no  special  integration  requirements  are  identified,  while 
others  will  require  parameter  setting,  glue  code,  ><nd  encapsulation.  Sandy  writes  the  document 
and  includes  a  number  of  examples  for  each  likely  kind  of  integration  technique.  Meanwhile,  Chris 
makes  sure  that  the  AE  process  activities  that  receive  assets  as  input  provide  for  asset  integration. 

Ensuring  Completion  of  Process  Modification  Planning  Deliverables 

Chris  has  now  integrated  CFRP  Asset  Utilization  processes  with  the  existing  MSA  AE  process  to 
produce  a  draft  reuse-based  AE  process.  Chris  schedules  a  series  of  off-site  meetings  with  Pat  and 
Kim  to  evaluate  and  refine  the  proposed  process  and  to  produce  a  new  life  cycle  document  that 
reflects  the  process.  They  use  the  existing  MSA  life  cycle  document  as  one  basis  for  guidance  and 
comparison.  The  time  spent  developing  the  new  life  cycle  document  is  a  series  of  learning  activities 
that  gradually  improve  both  the  reuse- based  AE  process  and  the  life  cycle  document. 

During  this  period,  Chris,  Pat,  and  Kim  jointly  develop  guidelines  for  incremental  adoption  of  the 
new  process,  in  accordance  with  the  MSA  Process  Modification  Plan.  They  agree  that  the  life 
cycle  document  (rather  than  the  more  abstract  AE  process)  should  be  the  principal  focal  point 


Pa^e  28 


30  September  1993 


STARS- VC-A018/002/00 


for  recommending  incremental  changes  that  will  lead  toward  the  target  process.  In  developing  the 
guidelines,  they  realize  that  they  need  to  address  infrastructure  evolution  as  well  as  process  evolu¬ 
tion.  They  address  all  the  adoption  issues  that  Chris  noted  while  integrating  the  Asset  Utilization 
processes  with  the  AE  process,  and  they  identify  some  additional  infrastructure  evolution  issues,  as 
well.  For  example,  they  note  that  configuration  management  tools  will  need  to  have  progressively 
more  sophisticated  capabilities  and  that  mechanisms  such  as  inspections  and  reviews  may  take 
on  increasing  formality  to  support  the  target  process.  After  four  off-site  meetings,  the  threesome 
deliver  the  new  life  cycle  document.  Radio  Signal  Analysis  and  Communications  Interception  Pro¬ 
grams’  Life  Cycle  for  Next-Generation  Projects  in  MSA.  Accompanying  the  document  are  a  set  of 
incremental  adoption  guidelines  for  managers  and  another  set  for  engineers. 

In  reviewing  the  MSA  reuse-based  AE  process  he  has  developed,  Chris  is  struck  by  the  need  for 
better  coordination  among  activities.  Asset  Identification  and  Selection  would  both  benefit  from 
the  expertise  and  lessons  learned  that  could  be  provided  by  staff  experts  and  former  users  and 
developers.  Asset  Tailoring  requires  coordination  between  asset  utilizers  and  the  Maintenance  group 
when  asset  modification  is  needed,  to  be  sure  that  the  assets  will  still  meet  reusability  requirements 
for  future  uses  and  that  the  changes  are  truly  needed  to  accomplish  the  utilizers’  needs.  In  light 
of  these  concerns,  Chris  recommends  to  Jan,  Pat,  and  Kim  that  they  form  a  reuse  coordination 
steering  committee  consisting  of  (a)  technical  contributors  who  will  assess  what  changes  need  to 
be  made,  and  (b)  managers  who  can  prioritize  changes  and  assign  software  engineering,  technical 
writing,  or  test  engineering  staff  to  implement  the  changes.  They  then  develop  a  plan  to  obtain 
T.  J.’s  support  for  changes  that  have  strategic  impact. 


Commentary 

MSA  is  an  organization  well  suited  to  the  process-driven  reuse-based  software  engineering  approach 
advocated  by  the  CFRP.  Their  R&D  organization  already  uses  well-defined  processes  to  plan  and 
guide  their  application  engineering  efforts.  Although  there  was  little  CFRP  usage  to  draw  on,  Chris 
believed  that  the  CFRP  documents  offered  compelling  arguments  that  an  application  engineering 
process  such  as  the  MSA  AE  process  might  be  successfully  modified  to  integrate  CFRP  Asset 
Utilization  processes.  He  aggressively  pursued  such  a  strategy. 

Chris  approached  the  process  modification  project  by  carefully  assessing  each  Asset  Utilization 
process  category  and  exploring  how  that  activity  would  be  integrated  into  the  MSA  AE  process.  A 
fundamental  insight  was  that  each  of  the  AE  process  activities  was  subject  to  modification.  In  fact, 
every  Asset  Utilization  process  category  is  incorporated  into  each  of  the  basic  AE  process  activities. 
This  results  from  the  fact  that  each  MSA  AE  activity  produces  a  particular  kind  of  life  cycle  work 
product  and  thus  can  reuse  a  corresponding  kind  of  asset.  The  CFRP’s  Asset  Utilization  process 
categories  are  designed  to  apply  to  any  kind  of  asset. 

Chris  addressed  a  number  of  organizational  issues  pragmatically  in  his  planning  task.  For  example, 
he  deferred  formal  Asset  Creation  and  Asset  Management  efforts  until  later,  and  he  accommodated 
the  fact  that  Jan’s  Maintenance  group  will  be  responsible  for  Asset  Management  and  primarily 
respoi'sible  for  Asset  Tailoring.  On  the  other  hand,  Chris  prompted  immediate  substantial  change 
by  negotiating  an  agreement  on  a  new  asset-centered  development  policy.  He  also  laid  the  ground¬ 
work  for  future  changes  by  promoting  learning  in  a  number  of  ways,  such  as  by  establishing  a  reuse 
coordination  steering  committee. 
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3.4  Scenario:  Using  the  CFRP  to  Plan  an  Asset  Creation  Project 
Point  of  View 

This  scenario  describes  the  activities  of  the  planner  of  an  Asset  Creation  project  within  j,  larger 
domain-specific  reuse  program. 


Context 


•  Setting 

Kate,  an  Air  Force  Major,  has  been  tasked  to  manage  an  Asset  Creation  project  within  a 
larger  reuse  program  being  undertaken  by  the  Product  Center  of  which  she  is  a  part.  The 
Center  has  adopted  the  CFRP  as  an  organizing  framework  for  its  reuse  program  and  has 
provided  CFRP  orientation  sessions  for  its  program  personnel.  The  Center  has  established 
a  library  in  which  to  maintain  the  artifacts  related  to  its  Reuse  Management  activities  (e.g., 
guidelines,  plans,  processes,  history,  lessons  learned). 

•  Goal 

Kate’s  primary  goal  for  the  activity  described  in  this  scenario  is  to  generate  a  CFRP-consistent 
plan  for  the  creation  of  domain-specific  assets  for  one  of  her  product  center’s  domains,  with 
special  emphasis  on  the  initial  domain  analysis  activity.  Her  secondary  goal  is  to  take  a 
deliberately  CFRP-consistent  approach  to  her  own  planning  activity  by  making  her  planning 
processes  explicit,  by  utilizing  existing  processes  and  plans  as  the  basis  for  her  work,  and  by 
capturing  her  processes,  products,  and  experience  for  reflection  and  potential  reuse. 

•  Assumptions 

—  The  dommn  for  the  Asset  Creation  project  has  been  selected  by  planning  activities  at 
the  reuse  program  level. 

-  The  project  is  the  second  Asset  Creation  project  to  be  planned  within  this  reuse  program. 

—  The  reuse  program  plan,  organi..ational  guidelines  (policies,  work  product  definitions, 
templates,  etc.),  and  the  management  related  products  of  other  projects  within  this 
reuse  program  are  in  the  Center’s  library. 

-  The  project  planning  effort  involves  defining: 

*  specific  project  processes, 

*  project  interconnections, 

*  project  infrastructure  requirements,  and 

*  resource  requirements  and  allocations. 


Inputs 

The  main  inputs  to  Kate’s  planning  activities  are  the  plans  created  for  the  reuse  program  of  which 
her  project  is  a  part,  and  organizational  guidelines  for  her  own  activity  and  her  work  products.  She 
also  has  as  input  the  plans  and  results  of  Make  Goods,  the  previous  Asset  Creation  project  in  the 
program.  A  more  detailed  listing  of  her  inputs  follows: 
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•  Reuse  Program  Plan 

-  Objectives  and  strategies  for  the  program 

-  Scope  of  the  program,  including  domain  selections  and  definitions,  with  associated  pro¬ 
cess  and  rationale  documentation 

-  Infrastructure  plan 

-  Program  evaluation  criteria 

—  Identification  of  Asset  Creation,  Management,  and  Utilization  projects  and  their  rela¬ 
tionships 

•  Requirements  and  templates  for  project  planning  work  products  and  project  library  informa¬ 
tion 

•  Management  work  products  from  Make  Goods 

-  Plans 

-  Process  definitions 

-  Project  evaluation  criteria 

-  Evaluation  results,  lessons  learned,  and  recommendations 

•  Existing  infrastructure  capabilities  and  associated  results  and  lessons  learned 

-  For  the  program  as  a  whole 

-  For  Make  Goods 


Outputs 

The  primary  products  that  Kate  will  generate  are  a  project  plan  and  a  definition  of  the  processes 
that  will  be  used  on  the  project.  Additional  outputs  include  records  of  Kate’s  own  processes  and 
insights.  In  more  detail,  the  outputs  are; 

•  Project  Plan 

-  Objectives  and  evaluation  criteria 

-  Tasks 

-  Infrastructure  requirements 
—  Resources 

—  Schedule 

-  Budget 

•  Process  definitions  for  planned  project  tasks 

•  A  record  of  Kate’s  reuse  planning  process,  along  with  notes,  insights,  and  lessons  learned 
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Scenario  Activity 
Getting  Started 

Because  she  is  committed  to  taking  a  CFRP-based  approach  to  her  work,  Kate  first  obtains  the 
STARS  CFRP  Definition  and  Application  documents.  She  reviews,  in  particular,  material  in  the 
CFRP  Definition  document  related  to  the  Reuse  Planning  family  of  the  Reuse  Management  idiom 
and  the  Asset  Creation  family  of  the  Reuse  Engineering  idiom.  She  also  familiarizes  herself  with 
the  content  of  the  CFRP  Application  document,  so  that  she  knows  where  to  look  for  specific 
information  later. 

Kate  has  been  given  a  hardcopy  of  the  plan  generated  for  the  reuse  program  of  which  this  Asset 
Creation  project  is  a  part.  This  plan  was  prepared  by  her  Branch  Chief  and  the  Center’s  Reuse 
Project  Officer,  who  used  the  CFRP  as  an  organizing  framework  for  the  plan.  Kate  reads  the  plan 
and  discovers  that  it  is  quite  high-level  and  gives  the  individual  project  planners  a  lot  of  discretion 
with  regard  to  their  planning  approach  and  their  interpretation  and  extension  of  the  plan. 

Because  she  and  her  organization  are  committed  to  moving  towards  a  process-driven,  reuse-based 
approach  to  all  of  their  work,  Kate  next  determines  whether  there  are  any  defined  processes  for 
planning  an  Asset  Creation  project  available  in  the  Center’s  library.  In  this  case  there  are  none 
(the  Make  Goods  planners  did  not  document  their  planning  processes),  so  she  must  rely  on  the 
CFRP  documents  for  guidance.  She  decides  to  maintain  a  journal  of  her  activities  to  capture  the 
planning  process  for  her  own  review  and  for  possible  reuse.  She  creates  a  project  library  (as  an 
extension  of  the  Center’s  library)  in  which  to  store  this  journal,  her  planning  work  products,  and 
project  history.  She  also  locates  electronic  versions  of  the  Center’s  reuse  program  plan  (so  that  she 
can  incorporate  material  from  that  plan  into  her  own,  as  appropriate),  and  the  plans  and  products 
of  Make  Goods. 

Developing  the  Plan 

In  her  planning  process,  Kate  intends  to  undertake  activities  in  each  of  the  process  categories  in 
the  Reuse  Planning  family  (Assessment,  Direction  Setting,  Scoping,  Infrastructure  Planning,  and 
Project  Planning).  She  decides  to  start  her  activity  in  each  category  by  reviewing  the  decisions 
and  guidance  inherited  from  the  reuse  program,  as  described  in  the  reuse  program  plan.  Before 
proceeding  with  her  planning,  Kate  re-reads  the  section  of  the  CFRP  Definition  document  that 
describes  the  process  categories  involved  in  Asset  Creation  (Domain  Analysis  and  Modeling,  Domain 
Architecture  Development,  and  Asset  Implementation)  and  reviews  the  IDEFo  diagrams  for  that 
family  in  the  CFRP  Application  document.  She  now  feels  prepared  to  start  on  her  plan. 

The  high-level  assessment  contained  in  the  program  plan  indicates  significant  expertise  in  the 
selected  domain  within  the  organization,  but  little  knowledge  of  domain  analysis  and  modeling 
techniques.  A  review  of  the  recommendations  and  lessons  generated  by  the  learning  activities 
associated  with  Make  Goods  indicates  that  an  existing  domain  analysis  method  was  tailored  and 
applied,  but  that  the  products  were  not  compatible  with  the  object-oriented  (00)  approach  that 
the  consumers  preferred  for  software  design.  Kate  notes  that  her  project  should  benefit  from  both 
the  in-house  expertise  in  domain  analysis  developed  on  Make  Goods  and  the  other  parts  of  the 
infrastructure  that  were  used  on  that  effort,  but  she  takes  special  note  of  the  need  for  compatible 
software  design  approaches  across  the  producer-consumer  communities. 
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Kate  proceeds  to  set  the  direction  and  establish  the  objectives  for  this  project  (which  she  dubs  Make 
More)  by  applying  and  specializing  the  Center’s  reuse  program  objectives  to  the  project.  She  also 
looks  at  the  Make  Goods  objectives,  considers  how  well  they  were  met,  and  notes  the  associated 
learning  insights.  As  a  result  of  this  analysis  and  her  earlier  assessment  activity,  Kate  adds  the 
objective  of  making  Asset  Creation  products  compatible  with  the  consumers’  preferences.  However, 
because  of  the  uncertainty  in  this  area,  she  modifies  another  project  objective  by  reducing  the  target 
percentage  of  domain  assets  that  wiU  be  reused  by  application  projects  within  the  next  two  years 
from  80%  to  70%.  As  this  last  step  indicates,  Kate  ensures  that  each  objective  is  accompanied  by 
metrics  or  success  criteria  to  enable  evaluation  of  whether  or  not  the  objective  was  achieved. 

The  program  plaji  establishes  the  overall  scope  for  the  project  (including  the  scope  of  the  domain). 
To  determine  if  any  further  constrmnts  on  the  project’s  scope  are  appropriate  at  this  time,  Kate 
considers  lessons  learned  about  the  scope  of  the  Make  Goods  project.  She  notes  that  the  participants 
in  that  project  concluded  that  they  had  taken  on  too  large  a  domain  and  that  as  a  result  there  were 
insufficient  resources  to  validate  the  products  as  planned.  She  decides  that,  rather  than  attempting 
to  re-scope  the  Make  More  domadn  herself,  she  will  require  that  the  domain  analysis  task  undertake 
its  own  scoping  activity,  and  issues  a  guideline  to  choose  depth  over  breadth.  She  includes  the  data 
reflecting  the  “size”  of  the  Make  Goods  dommn  and  the  resources  expended  on  that  domain  analysis 
as  an  appendix  to  her  plan. 

Kate  reviews  the  reuse  program’s  infrastructure  plan,  and  also  reviews  the  infrastructure  that  has 
already  been  implemented.  She  finds  that  the  organization  has  obtained  the  documentation  and 
training  materials  for  the  Domain  Analysis  Process  Model  (DAPM),  the  method  that  was  used  in 
Make  Goods.  She  notes  that  the  tailored  version  of  DAPM  used  by  Make  Goods  is  also  available. 
But  she  knows  that  method  will  not  meet  her  objectives  because  the  planned  consumers  of  the 
products  of  Make  More  include  the  same  object-oriented  group  that  used  the  products  of  Make 
Goods.  She  reviews  the  overall  experience  with  the  method  from  the  asset  creators’  perspective  and 
finds  that  it  is  favorable,  in  particular  because  of  its  thorough  documentation  and  a  modularity  that 
makes  it  readily  modifiable.  On  this  basis,  she  decides  to  spawn  an  effort  to  define  a  method  that 
capitalizes  on  the  domain  analysis  processes  of  the  DAPM  and  yields  products  that  are  compatible 
with  an  object-oriented  approach.  She  judges  the  successful  development  of  such  a  method  to 
be  critical  to  achieving  her  objectives,  so  she  directs  that  the  task  begin  immediately  and  that  it 
include  a  smadl  pilot  application.  She  temporarily  suspends  her  own  planning  until  she  is  confident 
that  a  workable  method  can  be  developed. 

Refining  the  Domain  Analysis  Method 

John,  a  Captain  in  Kate’s  Branch  and  a  recent  graduate  of  the  Air  Force  Institute  of  Technology’s 
Computer  Science  program,  is  chosen  for  this  task  because  of  his  experience  with  object-oriented 
design  and  his  enthusiasm  for  the  move  towards  reuse-based  software  development.  John  was 
exposed  to  the  CFRP  in  a  one-day  orientation  sponsored  by  the  reuse  program,  and  he  realizes  that 
his  task  can  be  viewed  as  a  Reuse  Learning  activity  (specifically,  an  Innovation  Exploration  task) 
within  the  Make  More  Infrastructure  Planning  activity.  In  particular,  John  views  this  Innovation 
Exploration  task  as  a  distinct  Plan-Enact-Leam  loop  embedded  within  Infrastructure  Planning. 
He  recognizes  that  his  own  planning  activities  will  be  influenced  by  planning  decisions  inherited 
from  Kate’s  work  and  from  the  reuse  program  plan. 

John  starts  his  work  by  quickly  reviewing  the  CFRP  Reuse  Planning  processes.  With  regard  to 
assessment,  he  notes  that  he  lacks  domain  analysis  experience  and  will  need  to  spend  some  time 
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coming  up  to  speed.  In  setting  his  direction,  he  realizes  that  his  organization  has  made  a  substantial 
investment  in  the  existing  domain  analysis  method  (DAPM)  and  the  object-oriented  application 
development  methods  that  are  in  use,  in  terms  of  expertise,  tools,  documentation,  and  training. 
He  thus  establishes  an  objective  to  retain  as  much  of  these  existing  methods  as  possible  to  take 
maximum  advantage  of  the  established  investment.  In  scoping  the  effort,  John  decides  that  the 
pilot  project  wUl  focus  on  a  small  subset  of  the  Make  Goods  domain  because  the  project  should 
be  able  to  leverage  the  existing  Make  Goods  DAPM  products  to  quickly  assess  the  new  method. 
Infrastructure  planning  for  John’s  task  involves  verifying  that  the  documentation  and  training 
materials  for  DAPM,  the  DAPM  support  tools  used  by  Make  Goods,  and  the  latest  version  of  the 
00  design  tool  favored  by  the  organization  are  available.  In  planning  resources  and  schedules  for 
this  effort,  he  estimates  that  he  will  work  half  time  for  about  eight  weeks  and,  for  the  four-week 
pilot  project,  will  require  the  half-time  support  of  Lee,  a  Second  Lieutenant  who  worked  on  Make 
Goods. 

John  gets  into  action  by  first  reviewing  several  other  domain  analysis  methods  (in  this  case,  Feature 
Oriented  Domain  Analysis,  Organization  Domain  Modeling,  and  JIAWG  Object-Oriented  Domain 
Analysis,  all  referenced  in  Appendix  B  of  the  CFRP  Application  document)  to  get  some  broad 
understanding  of  the  topic.  He  then  studies  the  DAPM  documentation  and  trmning  material,  the 
Make  Goods  tailoring  of  the  DAPM  process,  and  the  domain  products  that  Make  Goods  generated. 

After  some  consideration  of  the  relevant  issues,  and  several  discussions  with  the  developer  of  DAPM, 
John  decides  that  a  hybrid  DAPM/00  method  is  feasible  and  proceeds  to  develop  such  a  method. 
The  hybrid  method  uses  the  DAPM  techniques  of  vocabulary  analysis,  conceptual  clustering,  and 
faceted  classification  for  identifying  objects  and  for  deriving  a  conceptual  domain  model,  while 
object-oriented  analysis  (OOA)  and  object-oriented  design  (OOD)  techniques  and  notation  are 
used  to  formalize  and  document  a  domain  architecture  and  component  specifications. 

After  John  defines  and  documents  the  new  method,  named  Domain  Analysis  For  Object  Oriented 
Development  (DAFOOD),  John  and  Lee  undertake  the  pilot  application,  which  involves  redoing 
the  Make  Goods  work  in  the  small  subdomain  John  identified  earlier.  They  apply  DAFOOD 
as  documented  and  generate  00-compatibIe  products,  but  experience  some  uncertainty  in  the 
transformation  of  the  DAPM  products  into  OOA  concepts  and  notation. 

Their  commitment  to  a  CFRP-based  approach  to  their  work  prompts  John  and  Lee  to  take  a  look 
at  the  Learning  processes  before  declaring  themselves  done.  They  engage  in  some  observation  and 
evaluation  of  their  small  project  to  see  what  can  be  learned.  They  analyze  the  DAFOOD  method  by 
determining  the  percentage  of  DAPM  and  00  activities  that  were  incorporated  into  DAFOOD  and 
counting  the  number  of  changes  that  were  maule  to  those  activities  during  DAFOOD  development. 
Based  on  this  analysis,  they  decide  that  they  have  achieved  their  objective  of  minimizing  changes 
to  existing  methods. 

However,  as  they  analyze  the  effectiveness  of  the  DAFOOD  method  in  their  pilot  application, 
they  become  concerned  that  their  approach  to  integrating  the  existing  methods  may  have  led  to 
difficulties  in  transitioning  between  the  DAPM  and  00  aspects  of  DAFOOD.  They  decide  to  review 
the  notes  they  took  during  the  pilot  and  carefuUy  analyze  the  steps  in  which  the  problems  occurred. 
They  agree  that  one  of  the  DAPM  products  is  not  completely  specified,  and  the  ill-defined  process 
of  mapping  that  product  to  the  00  notation  leaves  much  to  the  discretion  and  imagination  of  the 
person  doing  the  analysis.  To  address  these  problems,  John  proposes  several  enhancements  to  the 
DAPM  product  specification  and  introduces  two  new  explicit  DAPM-to-00  transition  steps  into 
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the  method.  Lee  tries  these  changes  and  concludes  that  the  transition  now  goes  more  smoothly. 
They  generate  a  recommendation  that  the  modified  version  of  DAFOOD  be  used  on  Make  More, 
and  suggest  that  careful  attention  be  paid  to  the  new  steps  because  they  were  not  fully  validated 
in  the  pilot. 

Developing  the  Plan  (Resumed) 

Having  p.  jated  in  some  of  the  Learning  sessions  with  John  and  Lee,  Kate  is  convinced  that  they 
have  a  viable  new  domain  analysis  method.  She  recognizes  that  the  DAFOOD  method  includes 
architecture  development  as  well.  In  discussions  with  John,  she  learns  that  it  is  premature  to 
commit  to  a  particular  approach  to  Asset  Implementation  because  that  determination  will  best  be 
made  towards  the  end  of  the  DAFOOD  process.  Thus  Kate  determines  that  her  Asset  Creation 
planning  activity  at  this  time  encompasses  a  combination  of  Domsun  Analysis  and  Modeling  and 
Domain  Architecture  Development  processes.  Since  she  has  already  seen  the  benefit  of  Learning 
activities,  she  decides  to  include  explicit  Reuse  Learning  tasks  in  her  plan  as  well. 

Kate  reviews  the  technical  infrastructure  requirements  for  the  DAFOOD  prore^<.  and  determines 
whether  the  needed  platforms  and  tools  are  available.  In  this  case  one  complete  kuitr  m  house 
and  available,  but  a  second  suite  is  required.  These  additional  infrastructure  nee«l»  are  rrfle«-i«>d  in 
the  financial,  tasking,  and  scheduling  sections  of  the  emerging  project  plan. 

Kate  next  reviews  the  organizational  and  educational  infrastructure  to  supp«>rt  the  D.M'OOD 
process  and  associated  technology.  She  notes  that  the  organizational  structure,  poliries.  pri»cedures, 
incentives,  etc.,  that  have  been  established  by  the  overall  organization  and  by  the  reuse  program 
seem  generally  sufficient  to  staff  the  project  and  provide  general  support.  Kate  finds  that  vendor 
courses  are  available  for  the  selected  tools  and  that  the  training  material  as  modified  for  Make 
Goods  is  also  available.  However,  the  training  material  will  need  to  be  modified  further  to  reflect 
the  changes  that  resulted  in  the  DAFOOD  method.  Again,  this  need  is  reflected  in  the  financial, 
tasking,  and  scheduling  sections  of  the  plan. 

Kate  can  now  solidify  the  project  resource  requirements  and  make  specific  recommendations.  Based 
on  review  of  the  documentation  of  the  selected  process  (DAFOOD)  and  the  staffing  of  Make  Goods, 
Kate  defines  the  detailed  staffing  requirements  for  the  project,  in  terms  of  job  categories  and  skills  as 
well  as  numbers.  She  reviews  the  domain  selection  report  generated  by  the  reuse  program  planning 
effort  to  identify  domain  experts.  She  identifies  in  the  plan  the  individuals  whom  she  believes  are 
best  qualified  to  perform  the  DAFOOD  processes,  and  identifies  their  organizational  position  and 
relationships.  She  then  establishes  a  recommended  budget  and  spend  plan  for  the  project,  broken 
down  into  monthly  intervals. 

Finalizing  the  Plan 

Kate  completes  the  proposed  project  plan  in  accordance  with  guidelines  and  templates  established 
by  her  organization.  She  distributes  this  material  to  planned  staff  members,  higher-level  managers, 
identified  domain  experts,  and  selected  personnel  from  Make  Goods  for  their  review.  She  negotiates 
and  modifies  the  plan  in  response  to  feedback  from  the  reviewers  and  then  submits  the  plan  for 
approval. 
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Recording  History  and  Lessons 

While  she  waits  for  approval  Kate  reviews  the  content  of  the  project  library  thus  far  to  ensure  that 
all  work  products  are  present  and  current.  She  also  reviews  and  completes  the  project  history  to 
date.  She  finally  completes  and  reviews  her  journal  of  the  process  followed  in  this  planning  activity. 


Commentary 

In  this  scenario  we  have  seen  Kate  using  the  CFRP  both  to  guide  her  own  planning  activities  and 
to  shape  her  plan  for  the  Make  More  project.  She  performed  each  of  the  process  categories  of  the 
Reuse  Planning  family.  When  she  began  the  Infrastructure  Planning  process  and  reviewed  some 
lessons  from  the  Make  Goods  project,  she  realized  that  she  needed  to  ensure  that  there  was  a  viable 
domain  analysis  method  before  committing  to  a  Make  More  effort. 

Kate  then  initiated  an  Innovation  Exploration  process  to  combine  two  existing  technologies  to  form 
a  new  domain  analysis  method.  In  that  task,  John  and  Lee  stepped  through  a  Plan-£nact-L«am 
loop  to  develop  the  DAFOOD  method  and  assess  it  through  application  in  a  pilot  project.  They 
then  cycled  through  the  loop  a  second  time  to  evolve  the  method  to  address  problems  identified 
during  the  pilot. 

Kate  based  the  tasks  in  her  plan  on  both  the  Asset  Creation  and  Reuse  Learning  process  cate¬ 
gories.  With  regard  to  Asset  Creation,  she  mapped  the  Domain  Analysis  and  Modeling  and  Do¬ 
main  Architecture  Development  categories  to  a  single  task,  and  postponed  any  planning  of  Asset 
Implementation. 
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3.5  Scenario:  Using  the  CFRP  to  Plan  a  Reuse  Program 
Point  of  View 

This  scenario  describes  the  activities  of  a  technical  planner  beginning  the  Reuse  Planning  process 
for  an  entire  reuse  program.  This  includes  the  high-level  planning  of  Asset  Creation,  Management, 
and  Utilization  projects  within  the  scope  of  the  overall  program. 


Context 

•  Setting 

The  Veteran’s  Administration  (VA)  has  issued  an  RFP  for  a  next-generation,  integrated 
multimedia-based  hospital  information  system,  called  the  VA  Medical  Open- Architecture  Sys¬ 
tem  (VAMOS).  The  system  is  to  be  deployed  nationally  within  the  VA  hospital  system  over  a 
ten-year  period.  The  RFP  requires  that  proposals  include  a  Reuse  Program  Plan  (RPP)  that 
addresses  the  full  VAMOS  deployment  cycle  and  demonstrates  technical  and  methodological 
competence  in  reuse. 

MediSoft  Corporation,  a  nnid-size  firm  specializing  in  real-time  medical  software  engineering 
applications,  intends  to  submit  a  proposal  for  the  VAMOS  contract  and  has  prepared  an  initial 
draft  of  the  proposal.  Jack  is  a  MediSoft  software  program  manager,  with  a  background 
in  real-time  medical  software  engineering  applications,  who  has  become  known  as  a  reuse 
advocate  within  the  company.  He  is  tasked  with  reviewing  the  draft  proposal  to  assess  its 
responsiveness  to  reuse  issues,  and  to  make  specific  recommendations  for  the  RPP  that  will 
be  integrated  into  the  proposal.  Jack  has  recently  attended  an  orientation  on  the  CFRP,  and 
decides  to  use  this  task  as  an  opportunity  to  apply  the  CFRP  in  the  planning  process. 

•  Goal 

Jack  must  produce  a  review  of  relevant  aspects  of  the  draft  proposal,  develop  a  set  of  rec¬ 
ommendations  for  the  RPP,  and  show  the  impact  of  his  recommendations  on  the  current 
proposal  strategy.  He  will  first  present  his  review  and  recommendations  to  the  proposal 
team,  then  to  MediSoft’s  software  division  manager,  who  has  final  say  on  the  overall  proposal 
effort.  Technical  managers  must  be  convinced  that  his  plan  offers  a  coherent  approach  to  risk 
reduction,  reuse  adoption,  and  technology  transfer  issues.  Jack  also  wants  the  presentation 
to  incorporate  CF|IP  concepts  and  terminology  in  a  way  that  will  communicate  effectively 
to  the  proposal  team  and  to  the  VA’s  proposal  evaluators. 

•  Assumptions 

-  In  current  VA  software  practice,  a  large,  standardized  MIS  system  is  in  use  throughout 
the  national  VA  hospital  network.  Each  major  module  of  this  standardized  system  is 
maintained  by  a  different  regional  VA  programming  center.  This  approach  has  served 
to  minimize  configuration  management  complexity  for  the  VA,  and  has  worked  weU  in 
the  MIS  context. 

-  MediSoft  Corporation  has  a  culture  of  informal,  ad  hoc  reuse.  The  corporation  has 
recently  established  an  objective  to  transition  to  a  more  domain-specific  reuse-based 
approach  to  software  engineering.  However,  no  systematic  or  managed  intemaJ  reuse 
program  has  yet  been  established. 
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-  Neither  the  MediSoft  proposal  team  nor  the  VA’s  proposal  evaluators  have  significant 
knowledge  of  the  CFRP. 


Inputs 

•  Relevant  sections  of  the  RFP  calling  for  the  Reuse  Program  Plan  (RPP) 

•  The  current  draft  MediSoft  proposal 

Outputs 

•  A  list  of  review  comments  on  the  current  draft  proposal 

•  The  RPP  recommendations,  in  outline  form 


Scenario  Activity 
Setting  the  Context 

Jack  begins  by  reading  the  VAMOS  RFP  and  re-reading  the  CFRP  Definition  document,  then 
reading  the  draft  MediSoft  proposal.  He  chooses  this  sequence  in  order  to  reflect  upon  the  RFP 
from  a  CFRP  perspective,  before  being  too  influenced  by  the  approach  in  the  draft  proposal. 

VAMOS  RFP  Review:  The  VAMOS  RFP  specifies  certain  reusability  issues  the  RPP  must  address, 
including: 


•  adaptability  to  multiple  hospital  environments 

•  a  domain  architecture  aUowing  incorporation  of  new  medical  and  communications  technology 
as  it  becomes  available 

•  planning  for  possible  scaling  and  adaptation  to  other  VA  application  areas 


Jack  wonders  whether  these  points  constitute  a  complete  list  of  the  reuse  issues  deemed  relevant  to 
the  VA,  or  are  intended  only  as  examples  that  reflect  a  more  comprehensive  set  of  reuse  objectives. 
He  decides  to  assume  the  latter  in  his  planning,  and  concludes  that  the  VA  customer  will  respond 
positively  to  an  innovative  technical  approach  to  reuse  in  the  VAMOS  proposal.  However,  Jack 
makes  a  note  to  verify  these  key  points  with  the  proposal  team. 

CFRP  Review:  Reflecting  on  his  recent  CFRP  orientation.  Jack  asks  how  the  VAMOS  program  fits 
within  the  CFRP  framework.  He  determines  that  the  reuse  program  called  out  in  the  VAMOS  RFP 
corresponds  quite  closely  to  a  CFRP  “reuse  program”  (specifically,  a  Plan-Enact-Leam  process 
cycle  encompassing  one  or  more  Reuse  Engineering  projects).  Jack  expects  that  there  may  be 
several  Asset  Creation  projects  within  the  reuse  program,  each  corresponding  to  an  entire  domain 
engineering  effort  to  be  initiated  within  the  VAMOS  program.  Similarly,  he  sees  that  efforts  to 
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develop  and  maintain  major  VAMOS  modules  and  perform  overall  VAMOS  system  integration 
could  be  defined  as  separate  Asset  Utilization  projects.  He  does  not  see  a  clear  analogue  to  an 
Asset  Management  project  in  the  RFP,  so  he  makes  a  note  to  review  the  draft  proposal  regarding 
this  issue  and  address  it  in  his  own  RPP  recommendations. 

Jack’s  CFRP  orientation  emphasized  that  a  reuse  program  may  consist  of  a  sequence  of  iterations  or 
“reuse  cycles”  (as  described  in  the  Reuse  Management  section  of  the  CFRP  Definition  document). 
Jack  reviews  the  VAMOS  RFP  and  considers  the  impact  of  partitioning  the  program  into  multiple 
phases,  structured  in  terms  of  CFRP  reuse  cycles.  Jack  decides  to  review  the  MediSoft  proposal 
before  pursuing  these  ideas  further. 

Draft  MediSoft  Proposal:  The  draft  MediSoft  proposal  is  based  on  development  of  a  standard  generic 
architecture  that  will  be  deployed  at  each  VAMOS  site  along  with  some  mandated  standards  and 
components.  Custom  applications  based  on  these  standard  capabilities  will  be  written  to  satisfy 
the  unique  needs  of  each  hospital  environment.  Jack  recognizes  that  this  approach  is  modeled 
on  the  current  software  practice  for  managing  the  VA’s  nationwide  MIS  system  (as  described  in 
Assumptions,  above). 

Although  this  approach  is  consistent  with  current  VA  practice.  Jack  believes  it  will  prove  inadequate 
for  the  complex  and  rapidly  changing  application  area  of  real-time  patient  monitoring  and  data 
analysis  software.  Based  on  his  applications  knowledge,  Jack  believes  a  more  flexible  architecture 
framework  is  needed  to  address  commonality  and  variability  across  the  range  of  intended  VAMOS 
installations.  Such  flexibility  will  be  even  more  critical  when  addressing  the  need  to  adapt  VAMOS 
capabilities  to  other  VA  application  areas,  as  stated  in  the  RFP.  Jack  notes  that  this  technical 
approach  reflects  the  concept  of  domain-specific,  architecture-based  reuse  advocated  in  the  CFRP. 
He  also  realizes  (with  some  concern)  that  such  an  approach  will  significantly  impact  both  the 
development  plan  and  architecture  for  the  system  in  the  current  proposal.  He  summarizes  these 
comments  for  his  presentation. 

Determining  the  Planning  Approach 

Jack  now  has  a  CFRP  context  for  his  planning  activity  and  an  initial  sense  of  the  technical  approach 
he  will  advocate  for  the  RPP.  Before  he  can  begin  detailed  work  on  the  RPP,  Jack  feels  he  needs  to 
establish  an  overall  planning  approach.  He  looks  for  a  well-defined  reuse  planning  process  he  can 
follow,  or  at  least  a  good  example  of  a  reuse  program  plan  to  give  him  guidance,  but  finds  nothing 
aside  from  the  CFRP  itself. 

Jack  thus  reviews  the  CFRP  Reuse  Planning  process  categories  to  gain  some  insight  into  how  to 
proceed.  He  realizes  that  he  has  already  performed  some  degree  of  Assessment  and  decides  that 
he  will  continue  to  weave  Assessment  activities  throughout  his  planning  process  as  he  uncovers 
new  aspects  of  the  VAMOS  situation  requiring  reflection  and  evaluation.  Jack  notes  that  the 
overall  direction  and  scope  of  the  program  are  defined  in  the  RFP  and  refined  in  the  MediSoft 
proposal,  so  he  decides  not  to  pursue  Direction  Setting  and  Scoping  as  distinct  major  activities 
within  his  planning  process.  He  acknowledges,  however,  that  he  may  further  refine  the  direction 
and  scope  while  performing  other  planning  activities,  and  he  realizes  that  he  has  already  broadened 
the  technical  scope  by  electing  to  propose  a  more  ambitious  architectural  approach.  Jack  wonders, 
given  the  high-level  nature  of  the  RPP,  if  there  will  be  a  need  to  plan  the  reuse  infrastructure  in 
any  detail.  He  decides  that  he  will  not  perform  Infrastructure  Planning  as  a  discrete  planning  step 
at  this  staige  in  his  task,  but  will  address  infrastructure  issues  appropriately  as  they  arise. 
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In  the  end,  Jack  concludes  that  the  main  thrust  of  his  planning  task  will  be  the  CFRP  Project 
Planning  activity,  with  other  planning  activities  interleaved  appropriately.  He  decides  that  the 
major  objectives  of  this  activity  will  be  to  define  a  set  of  overall  program  phases,  define  candidate 
reuse  projects  and  the  kinds  of  interactions  that  will  take  place  among  them,  and  address  issues 
associated  with  the  incremental  adoption  of  the  reuse  approach  within  the  program. 

Jack  next  considers  the  general  level  of  technical  detail  and  overall  planning  emphasis  that  should 
be  reflected  in  the  VAMOS  RPP.  The  RPP  must  address  the  entire  ten-year  system  acquisition 
and  roll-out  period,  and  Jack  decides  that  it  wiU  be  impossible  at  this  time  to  anticipate  the 
technical  issues  that  will  arise  throughout  this  period.  He  thus  concludes  that  it  is  inappropriate 
to  plan  the  Reuse  Engineering  approach  in  detail  and  decides  that  the  RPP  should  not  discuss 
Reuse  Engineering  processes  below  the  CFRP  family  level  (i.e..  Asset  Creation,  Management, 
and  Utilization).  However,  he  believes  he  can  lay  out  a  relatively  detailed,  phased  planning  and 
management  approach  that  will  be  applicable  across  the  ten-year  period,  so  he  decides  that  he  will 
try  to  incorporate  Reuse  Planning,  Enactment,  and  Learning  processes  into  the  RPP  at  the  CFRP 
category  level  as  much  as  possible. 

Jack  remembers  from  his  CFRP  orientation  that  the  Reuse  Management  processes  must  be  tsdlored 
to  and  integrated  with  the  organization’s  overall  program  and  project  management  processes.  To 
gain  additional  insight  into  the  overall  MediSoft  processes  as  they  are  applied  in  the  VA  context, 
he  contacts  the  program  manager  for  an  earlier  MIS-based  hospital  system  developed  by  MediSoft 
for  the  VA.  Jack  talks  with  the  program  manager  about  how  initial  planning  was  done  and  what 
lessons  were  learned.  Jack  concludes  that  many  aspects  of  the  earlier  management  process  will  be 
applicable  to  the  VAMOS  program,  and  he  writes  down  a  number  of  ideas  about  how  to  integrate 
those  aspects  with  the  CFRP  Reuse  Management  processes.  The  program  manager  agrees  to  review 
the  RPP  when  it  is  completed. 

Defining  the  Program  Phases 

Jack  is  now  prepared  to  begin  defining  the  plan.  In  thinking  about  how  the  overall  program  should 
be  structured,  he  revisits  the  notion  of  multiple  program  phases  based  on  CFRP  reuse  cycles, 
which  he  had  considered  when  reviewing  the  CFRP  earlier.  To  improve  his  understanding  of  these 
concepts,  Jack  re-reads  the  portion  of  the  Reuse  Management  section  in  the  CFRP  Definition 
document  that  discusses  reuse  programs,  cycles,  and  initiatives.  Based  on  the  knowledge  he  has 
gained  about  the  RFP  and  the  draft  proposal,  he  decides  to  recommend  an  approach  with  three 
major  phases,  as  follows: 


•  A  first  cycle  (the  “reuse  initiative”)  to  explore  technical  alternatives,  develop  prototype  VA¬ 
MOS  assets,  and  verify  them  by  constructing  VAMOS  system  prototypes  using  the  assets. 

•  A  second  cycle  encompassing  development  of  “production-quality”  assets  and  reuse-based 
development  and  deployment  of  one  full  VAMOS  system. 

•  Subsequent  cycles  that  address  system  adaptation  by  regional  centers,  as  well  as  maintenance 
and  enhancement  of  the  assets  and  systems. 

In  this  cyclic  context,  lessons  learned  and  recommendations  for  improvement  flow  from  the  learning 
activities  of  each  cycle  to  the  planning  activities  for  the  following  cycle.  Jack  prepares  an  illustration 
depicting  this  phased  approach  that  he  will  include  in  his  presentation  to  the  proposal  team. 
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Planning  the  Program  Cycles 

As  Jack  begins  to  consider  how  to  structure  the  activities  within  the  program  cycles,  he  again 
reviews  the  Reuse  Management  section  of  the  CFRP  Definition  document.  As  he  is  reading,  he 
gradually  realizes  that  much  of  the  detail  he  had  expected  to  incorporate  into  his  plan  at  this  time 
will  have  to  be  deferred  to  planning  activities  within  the  individual  program  phases  because  he  lacks 
sufficient  context  at  his  level  of  planning.  In  thinking  about  these  issues,  Jack  suddenly  understands 
something  that  he  was  only  vaguely  aware  of  before:  his  focus  on  ‘^planning  the  planning”  processes 
for  the  RPP  is  an  example  of  the  concept  of  “recursion”  in  the  Reuse  Management  idiom,  as 
described  in  Appendix  A  of  the  CFRP  Definition  document.  He  re-reads  Appendix  A  to  verify 
this  interpretation  and  further  clarify  his  understanding  of  it.  The  concept  of  CFRP  recursion  had 
seemed  quite  abstract  to  Jack  during  the  CFRP  orientation,  and  he  is  intrigued  to  find  it  applicable 
to  his  own  planning  task.  He  decides  to  describe  his  discovery  of  a  practical  example  of  Cf'RP 
recursion  as  a  lesson  learned  for  the  CFRP  developers. 

Jack  proceeds  to  “plan  the  planning”  by  first  allocating  a  number  of  overall  program  planning 
activities  to  the  Reuse  Planning  processes  within  the  initial  program  cycle  (the  “reuse  initiative”). 
He  then  fleshes  out  the  cycle  by  elaborating  on  all  the  processes  within  the  overall  Plan-Enact-Learn 
loop.  He  describes  these  processes  in  as  much  detail  as  he  can  given  his  limited  perspective,  and 
also  places  them  in  the  context  of  the  overall  MediSoft  program  management  processes,  based  on 
what  he  learned  about  those  processes  earlier.  He  structures  the  other  program  phases  similarly, 
though  somewhat  differently  to  reflect  the  distinct  roles  each  of  the  phases  will  play  within  the 
overall  program. 

Jack  recognizes  that  the  proposed  CFRP-based  approach  to  reuse  will  be  unfamiliar  to  the  VA 
developer  and  user  organizations  and  to  contractor  organizations  such  as  MediSoft.  A  transition  to 
this  approach  will  require  substantial  technological  and  ctiltural  change  within  those  organizations. 
An  overall  strategy  must  be  defined  for  incremental  adoption  of  key  reuse  concepts  and  technology 
by  the  VAMOS  stakeholder  organizations  throughout  the  life  of  the  program,  with  a  particular 
emphasis  on  the  initial  program  cycle.  Jack  consults  Appendix  B  of  the  CFRP  Application  docu¬ 
ment  for  help  in  this  area  and  sees  that  the  STARS  Reuse  Strategy  Model  and  the  VCOE  Reuse 
Adoption  Guidebook  may  offer  assistance  in  developing  a  reuse  adoption  strategy.  After  obtain¬ 
ing  and  reviewing  these  documents.  Jack  outlines  a  high-level  transition  plan  involving  systematic 
assessment  and  evolution  of  reuse  capabilities  within  each  VAMOS  stakeholder  organization.  The 
plan  also  includes  activities  to  coordinate  reuse  adoption  across  the  stakeholders.  In  addition,  it 
includes  global  VAMOS  efforts  to  estabUsh  key  technical  capabilities  central  to  the  entire  program 
and  ensure  broad  acceptance  of  those  capabilities  among  all  stakeholders. 

One  implication  of  this  transition  plan  is  that  the  Assessment  activity  within  the  initial  program 
cycle  will  be  very  extensive.  It  will  involve  thorough  assessment  of  the  current  state  of  reuse  practice 
within  the  stakeholder  organizations,  and  it  will  incorporate  a  preliminary  Reuse  Learning  phase  in 
which  studies  and  experiments  are  performed  to  identify  potentially  applicable  processes,  methods, 
and  tools  for  initial  use  on  the  program.  The  results  of  this  expanded  Assessment  activity  will  then 
provide  sufficient  context  for  the  initial  Scoping  and  Infrastructure  Planning  activities. 

Planning  Reuse  Projects 

As  a  critical  component  of  his  reuse  transition  plan.  Jack  proposes  a  set  of  pilot  reuse  projects  in  the 
initial  program  cycle  as  part  of  the  overall  prototyping  and  feasibility  phase  for  VAMOS.  The  pilots 
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will  demonstrate  the  feasibility  of  domain-specific,  architecture-driven  reuse  within  the  VAMOS 
application  area.  Their  success  wiU  result  in  buy-in  from  VA  and  MediSoft  upper  management, 
product  line  managers  who  will  need  to  contribute  staff  and  resources,  and  engineers  who  will  work 
on  the  program  and  who  must  be  willing  to  use  the  assets  developed. 

Specifically,  Jack  sees  two  critical  areas  of  technical  risk  for  reuse  in  the  VAMOS  application  area, 
and  proposes  two  related  domain  engineering  pUot  projects  to  address  these  areas.  The  first  project 
will  focus  on  developing  a  prototype  architecture  for  the  overall  VAMOS  system  by  performing  a 
domain  analysis  on  a  selected  set  of  similar  architectures  from  existing  medical  imaging  systems 
in  the  commercial  sector.  This  project  will  serve  as  a  proof  of  concept  for  the  viability  of  the 
more  flexible  architectural  approach  Jack  has  proposed.  The  second  domsun  engineering  project 
will  focus  on  building  reusable  components  in  a  narrowly  scoped  domain.  This  project  will  serve 
as  proof  of  concept  for  the  viability  of  achieving  reuse  in  domains  with  tight  real-time  constraints, 
rapidly  changing  technology,  and  numerous  hardware  platform  and  peripheral  dependencies.  After 
consulting  with  personnel  from  various  product  lines.  Jack  suggests  ultrasound  data  management 
as  a  possible  domain  for  the  second  project. 

Jack  also  proposes  two  application  engineering  pilot  projects  that  correspond  directly  to  the  domain 
engineering  pilots.  These  projects  will  assess  and  apply  the  prototype  architecture  and  component 
assets,  both  to  validate  them  and  to  provide  feedback  to  improve  the  assets  and  the  processes  and 
methods  that  are  used  to  create  them. 

Next,  Jack  tries  to  develop  a  general  VAMOS  deployment  strategy  in  terms  of  CFRP  Asset  Creation, 
Management,  and  Utilization  projects.  He  envisions  a  number  of  domain  engineering  projects, 
including  outgrowths  of  his  initial  pilot  projects  and  additional  projects  addressing  domains  to  be 
selected  early  in  the  second  program  phase.  Jack  recalls  that  both  the  VAMOS  RFP  and  the  draft 
proposal  had  not  adequately  addressed  the  role  of  Asset  Management.  Jack  proposes  for  the  RPP 
that,  depending  on  the  types  of  reusable  assets  created,  one  or  more  VAMOS  ‘‘reuse  technology 
centers”  be  established,  each  responsible  for  a  different  component  domain  and  an  associated  Asset 
Management  project.  He  decides  to  emphasize  to  the  proposal  team  that  these  centers  could  be 
viewed  as  a  refinement  of  the  current  VA  partitioning  into  regional  programming  centers.  In  this 
view,  each  center  would  manage,  not  a  modiile  of  a  standard  system,  but  a  domain-specific  asset 
base  utilized  by  the  various  sites  where  instances  of  the  operational  VAMOS  system  are  installed. 
The  integration,  customization,  and  installation  of  these  operational  systems  at  VAMOS  sites 
would  constitute  Asset  Utilization  projects.  To  support  these  projects.  Jack  proposes  that  tools  be 
developed  to  customize  and  tailor  VAMOS  assets  for  incorporation  into  operational  systems. 

Planning  Reuse  Project  Interactions 

As  the  final  step  in  developing  the  RPP,  Jack  feels  he  needs  a  better  understanding  of  the  interac¬ 
tions  among  the  various  Asset  Creation,  Management,  and  Utilization  projects  he  has  delineated. 
He  realizes  that  this  interaction  will  be  quite  different  from  the  current  organizational  structure. 
Jack  decides  to  model  all  the  stakeholders  in  the  VAMOS  context  that  might  create  or  utilize  re¬ 
usable  assets,  even  if  his  reuse  approach  were  not  a^iopted.  To  his  surprise.  Jack  finds  a  number  of 
“layers”  of  potential  creators  and  utilizers,  including: 


1.  Prime  contractors,  who  will  create  the  overall  domain  architecture 

2.  Current  regional  software  centers,  who  will  adapt  modules  in  the  VA’s  existing  MIS  system 
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to  interface  with  VAMOS,  and  may  take  over  maintenance  responsibility  for  some  part  of 
VAMOS  as  well 

3.  Third-party  commercial  software  developers  of  niche  applications  to  be  integrated  into  the 
overall  VAMOS  architecture 

4.  System  integrators  and  technical  support  personnel  associated  with  each  hospital 

5.  Medical  specialists  and  database  administrators,  who  may  create  and  access  “medical  infor¬ 
mation  assets”  (codified  medical  knowledge  particular  to  various  hospital  specialty  centers) 
over  the  VAMOS  network 

6.  System  operators  and  technicians,  who  will  need  to  program  routine  procedures  into  the 
system 

When  the  various  domain  engineering  projects  and  tedinology  centers  in  his  proposed  RPP  are 
added  to  this  already  rich  set  of  stakeholders.  Jack  realizes  that  the  program  will  involve  many 
asset  producer-consumer  relationships,  along  with  more  conventional  project  interactions.  He 
modifies  his  VAMOS  deployment  strategy  in  some  ways  to  address  these  issues,  but  he  realizes  that 
a  more  in-depth  analysis  will  be  needed  in  the  initial  program  cycle  to  fully  flesh  out  the  strategy. 
In  considering  ways  to  perform  this  analysis,  Jack  recalls  the  CFRP  notion  of  “cascading”  markets, 
where  engineers  may  utilize  assets  in  one  reuse  context  in  order  to  create  different  kinds  of  assets 
in  another  reuse  context.  He  re-reads  Appendix  A  of  the  CFRP  Definition  document,  where  the 
CFRP  concept  of  cascading  is  described.  He  believes  that  this  notion  is  quite  applicable  to  the 
VAMOS  program,  and  could  lead  to  new  kinds  of  reusable  components  through  identification  of 
producer-consumer  relationships  that  otherwise  would  not  be  discovered. 

Jack  decides  to  recommend  that  the  Assessment  task  within  the  initial  program  cycle  be  closely 
coordinated  with  the  task  of  gathering  system  and  site  requirements  for  the  VAMOS  system  from 
each  of  the  stakeholder  organizations.  The  reuse  assessment  team  will  document  a  more  complete 
VAMOS  stakeholder  model  in  CFRP  terms  and  will  interview  selected  personnel  from  each  orga¬ 
nization  to  identify  reuse  capability  levels,  potential  reusable  artifacts  and  processes,  and  potential 
producer-consumer  roles. 

Finalizing  and  Presenting  Recommendations 

As  Jack  reflects  on  his  experience  in  applying  the  CFRP,  he  notes  that  the  CFRP  perspective  has 
helped  him  discover  at  least  two  potential  weaknesses  in  the  current  proposal’s  technical  approach: 
a  reliance  on  an  over-simplified  architecture  that  will  not  adequately  accommodate  the  complexity 
of  the  VAMOS  domain,  and  no  recognition  of  the  need  for  a  planned  Asset  Management  approach. 
He  also  notes  that  he  has  discovered  some  innovative  opportunities  that  might  otherwise  have  been 
missed,  such  as  the  insight  that  VAMOS  system  end-users  might  potentially  act  as  asset  creators 
for  medical  information  assets.  Jack  believes  his  reuse  plan  defines  a  sound  phased  approach 
for  managing  the  overall  program  and  individual  reuse  projects.  The  plan  also  offers  a  realistic 
reuse  transition  path  for  the  VA  environment  that  adequately  manages  risks  and  could  gain  the 
acceptance  of  the  MediSoft  team  —  quite  possibly  even  win  the  contract. 

Jack  prepares  a  set  of  viewgraphs  that  summarize  his  review  of  the  draft  proposal,  his  interpreta¬ 
tion  of  the  technical  challenges,  risks,  and  opportunities  within  the  RFP,  and  his  proposal  for  the 
RPP.  He  presents  the  material  to  the  proposal  team  and  receives  feedback.  Most  find  the  overall 
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approach  compelling  and  innovative.  Some  concerns  are  raised  about  the  difficulty  of  adequately 
communicating  the  concepts  in  the  proposal,  and  concern  is  also  expressed  about  the  impact  of 
major  changes  on  the  current  proposal  schedule.  Jack  incorporates  the  feedback  into  his  presenta¬ 
tion  to  the  division  head,  who  is  persuaded  to  accept  Jack’s  key  recommendations  and  instructs  his 
marketing  manager  to  begin  raising  the  VA  customer’s  awareness  of  CFRP  concepts  immediately. 
The  division  head  also  decides  that  all  proposal  teams  should  attend  an  initial  CFRP  orientation 
in  the  future. 


Commentary 

This  scenario  shows  Jack  using  high-level  CFRP  concepts  as  a  basis  for  reviewing  a  draft  proposal 
and  defining  a  new  reuse  program  plan.  In  his  planning  process,  he  directly  used  the  concepts  of 
a  reuse  program;  reuse  cycles;  a  reuse  initiative  phase;  reuse  engineering  projects:  Asset  Creation, 
Management,  and  Utilization  prot,.  •  families;  domain-specific  architecture-driven  reuse:  and  the 
Reuse  Planning  process  categories.  He  also  incorporated  these  concepts  into  his  plan. 

Jack  took  steps  to  integrate  reuse  planning  elements  with  MediSoft’s  overall  program  management 
practices  in  the  VA  context.  Jack  also  discovered  that  CFRP-based  reuse  proce»*e%  are  scalable 
and  applicable  at  more  than  one  level  of  planning.  Because  of  the  complexity  of  ho  planning  task. 
Jack  stumbled  on  the  need  to  define  lower-level  planning  processes  using  the  technique  of  CFRP 
recursion.  He  also  found  a  useful  application  of  the  notion  of  cascading  asset  creator,  manager,  and 
utilizer  markets. 

Jack  recognized  the  need  for  a  planned  approach  to  reuse  adoption  within  the  \'AMOS  program. 
With  the  help  of  two  documents  listed  in  Appendix  B,  he  developed  a  high-level  reuse  transition 
plan  addressing  the  overall  program  and  the  individual  VAMOS  stakeholder  organizations.  The 
plan  proposed  a  set  of  pilot  projects  that  not  only  address  key  technical  issues,  but  also  promote 
buy-in  to  the  reuse  approach  among  the  VAMOS  stakeholders. 
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3.6  Scenario  Review 

The  scenarios  are  designed  to  provide  concrete  examples  of  applying  the  CFRP  and  to  communicate 
the  central  themes  associated  with  the  CFRP  (presented  earlier  in  Table  1).  This  section  reviews 
and  analyzes  the  scenarios,  primarily  in  terms  of  how  they  communicate  the  CFRP  themes. 

The  themes  are  reflected  both  in  the  activities  performed  by  the  individuals  in  the  scenarios  and  in 
the  work  products  that  they  generate.  A  mapping  of  the  themes  to  the  scenarios  is  shown  concisely 
in  Table  2.  In  the  table  entries,  “H”  implies  that  there  is  a  high  correlation  between  a  theme  and 
a  scenario,  “L”  implies  that  there  is  low  but  signiflcant  correlation,  and  an  empty  entry  implies 
that  there  is  no  signiflcant  correlation.  The  first  five  of  the  themes  listed  in  the  table  are  the  major 
themes  in  this  document,  because  they  are  evident  across  all  of  the  scenarios.  The  other  themes 
are  less  pervasive. 

A  more  detailed  discussion  of  how  each  theme  is  addressed  by  the  scenarios  is  included  below: 


•  1.  A  reuse- based  approach  to  software  engineering  should  be  driven  by  well- 
defined,  repeatable  processes. 

A  central  aspect  of  scenario  1  is  the  process-driven  RedLine  approach  to  the  keu«*'  Manage¬ 
ment  task  of  reviewing  a  reuse  plan.  The  major  activity  in  scenario  2  is  the  integral Hin  of  the 
CFRP  Asset  Utilization  processes  into  the  existing  application  engineering  pr«>ce%»,  enabling 
process-driven  reuse  within  the  MSA  organization.  Scenario  3  features  the  definition  of  a 
domain  analysis  process  for  the  Make  More  project.  Scenario  4  shows  that  the  prores.s-driven 
aspects  of  reuse  extend  to  high  levels,  as  Jack  plans  the  management  of  the  VAMOS  program 
from  a  process  perspective. 

•  2.  Software  reuse  has  both  management  and  engineering  dimensions,  whose 
activities  are  captured  in  the  CFRP  idioms. 

In  scenario  1,  Jane  uses  both  the  Reuse  Management  and  Reuse  Engineering  idioms  to  struc¬ 
ture  her  view  of  the  reuse  plan’s  functions  and  relationships.  In  scenario  2,  Chris  uses  the 
Reuse  Engineering  idiom  as  a  basis  for  understanding  existing  MSA  reuse  practices  and  de¬ 
termining  which  aspects  of  reuse  should  be  emphasized  in  the  near  term.  In  scenario  3,  Kate 
and  John  both  “live”  the  CFRP  Reuse  Management  idiom  by  consciously  engaging  in  P-El-L 
p^oce^ses,  and  Kate  applies  the  Reuse  Engineering  idiom  concepts  in  her  planning  activity. 
In  scenario  4,  Jack  directly  incorporates  the  Reuse  Management  idiom  into  his  proposed  plan 
and  also  carefully  considers  the  implications  of  family  interrelationships  within  the  Reuse 
Engineering  idiom. 

•  3.  CFRP  process  categories  provide  a  definition  of  the  activities  involved  in  a 
process-driven,  domain-specific  reuse-based  approach  to  software  engineering. 

In  scenario  1,  Jane  assesses  the  reuse  plan  by  mapping  it  to  the  CFRP  categories  (as  well 
as  the  idioms  and  families);  as  a  result,  she  identifies  the  missing  Domain  Analysis  function. 
In  scenario  2,  Chris  integrates  each  of  the  Asset  Utilization  process  categories  into  the  MSA 
application  engineering  processes.  In  scenario  3,  Kate  and  John  are  guided  by  Reuse  Planning 
and  Learning  categories  in  defining  their  own  processes,  and  Kate  relies  on  the  Asset  Creation 
categories  to  tell  her  what  tasks  might  need  to  be  planned  and  how  they  are  related.  In 
scenario  4,  Jack  uses  the  Reuse  Planning  categories  to  characterize  and  guide  his  own  planning 
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Scenario 

CFRP  Themes 

/ 

2 

3 

4 

1. 

A  reuse-based  approach  to  software  engineering  should  be  driven  by  well- 
defined,  repeatable  processes. 

H 

H 

H 

2. 

Software  reuse  has  both  management  and  engineering  dimensions,  whose 
activities  are  captured  in  the  CFRP  idioms. 

H 

L 

H 

H 

3. 

CFRP  process  categories  provide  a  definition  of  the  activities  involved 
in  a  process-driven,  domain-specific  reuse-based  approach  to  software 

H 

H 

H 

L 

engineering. 

4. 

Reuse  should  be  applied  as  a  “first  principle”;  that  is,  reusable  products 
should  always  be  considered  as  the  basis  for  work  before  creating  new  prod¬ 
ucts;  experiences,  processes,  and  workproducts  should  always  be  recorded 
for  learning  and  for  possible  reuse. 

H 

H 

H 

L 

5. 

Measurement,  learning  and  managed  change  are  essential  and  pervasive  in 

H 

H 

H 

H 

reuse. 

6. 

Infrastructure  is  important  to  reuse  and  must  be  designed  to  support  it. 

H 

H 

L 

7. 

A  domain-specific,  architecture-driven  approach  to  reuse  is  important,  from 
both  an  engineering  and  a  management  perspective. 

H 

H 

L 

8. 

The  asset  producer,  broker,  and  consumer  roles  are  distinct  within  Reuse 
Engineering. 

i 

H 

H 

n 

9. 

The  CFRP  is  generic  with  respect  to  domauns,  technologies,  mrmagement 
styles,  and  economic  sectors. 

H 

H 

H 

H 

10. 

CFRP  processes  should  be  integrated  with  overall  planning  and  engineering 
practices. 

H 

H 

11. 

The  CFRP  is  a  process  modeling  language  with  mechanisms  to  support 
composition  of  complex  process  configurations. 

L 

H 

12. 

The  CFRP  is  scalable  and  applicable  at  different  organizational  levels. 

L 

L 

L 

13. 

The  CFRP  is  a  domain  model  and  high  level  process  architecture  for  the 
reuse  process  domain;  it  provides  a  basis  for  the  analysis  of  reuse  processes 
and  the  definition  of  reusable  process  assets. 

H 

L 

Table  2:  Mapping  Between  CFRP  Themes  and  Scenarios 


and  integrates  the  Reuse  Management  categories  into  the  planning  processes  to  be  performed 
within  the  proposed  reuse  program. 

•  4.  Reuse  should  be  applied  as  a  first  principle. 

Jane  in  scenario  1  and  Kate  in  scenario  3  use  a  library  of  reusable  assets  and  contribute 
their  work  to  a  library.  Jane  also  reuses  a  reusable  process,  BedLine.  In  scenario  2,  Chris 
emphasizes  an  asset-centered  development  process,  in  which  the  assets  available  for  reuse  can 
influence  application  requirements.  Chris  also  considers  measures  to  encourage  adoption  of 
this  approach  among  the  engineering  staff.  John  in  scenario  3  reuses  and  adapts  an  existing 
domain  analysis  process  model.  John  in  scenario  3  and  Jack  in  scenario  4  reuse  the  experience 
of  other  individuals  in  their  organizations. 

•  5.  Measurement,  learning,  and  managed  change  are  essential  and  pervasive  in 
reuse. 

In  scenario  1,  Jane  records  and  reflects  on  her  experiences  and  adds  material  to  her  own 
library  of  reusable  material.  Her  learning  activity  also  provides  a  guideline  to  enhance  the 
reusable  RedLine  process.  In  scenario  2,  Chris  emphasizes  the  need  for  incremental  evolution 
and  adoption  of  the  reuse-based  application  engineering  process  model,  and  he  also  addresses 
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issues  concerning  the  long-term  transition  towards  a  more  comprehensive  approach  to  reuse 
within  the  overall  MSA  organization.  Kate  in  scenario  3  takes  good  advantage  of  the  lessons 
learned  by  the  previous  Asset  Creation  project’s  learning  activity  and  avoids  another  mis¬ 
match  between  the  products  created  and  the  products  needed  by  the  users.  Also  in  scenario  3, 
John  and  Chris  measure  their  changes  to  the  existing  methods  and  evaluate  their  work  against 
their  objectives.  In  scenario  4,  Jack  plans  initial  learning  activities  that  will  be  needed  as 
the  reuse  program  gets  started,  and  he  develops  a  transition  plan  to  facilitate  reuse  adoption 
within  VAMOS  stakeholder  organizations.  Jack  also  reflects  on  what  he  has  learned  from 
using  the  CFRP  itself. 

•  6.  Infrastructure  b  important  to  reuse  and  must  be  designed  to  support  it. 

In  scenario  2,  Chris  incorporates  reuse  processes  into  an  existing  element  of  the  infrastruc¬ 
ture,  the  application  engineering  process.  Chris  also  reviews  other  aspects  of  the  existing 
infrastructure  (e.g.,  tools,  policies,  funding  models,  incentives)  and  subsequently  considers 
infrastructure  requirements  to  support  the  reuse-based  application  engineering  process  being 
deflned  (e.g.,  asset  consultation,  program  understanding  tools,  test  harnesses,  training).  In 
scenario  3,  a  significant  part  of  the  activity  involves  revising  an  element  of  the  existing  in¬ 
frastructure,  the  domain  analysis  process.  Planning  for  tools  to  support  the  process  is  also 
performed.  In  scenario  4,  Jack  considers  changes  in  educational  and  organizational  infras¬ 
tructure  that  will  be  needed  to  support  a  transition  to  his  proposed  reuse  approach. 

•  7.  A  domain-specific,  architecture-driven  approach  to  reuse  is  important,  from 
both  an  engineering  and  a  management  perspective. 

In  scenario  1,  Jane  notes  the  use  of  a  generic  architecture  to  develop  the  prototype  reuse 
plan  and  suggests  that  it  also  be  used  in  the  analysis  of  user  requirements.  In  scenario 
3,  the  purpose  of  the  project  being  planned  is  to  generate  a  domain-specific  model  and 
architecture.  In  scenario  4,  Jack  proposes  a  pilot  project  to  focus  on  the  VAMOS  domain- 
specific  architecture  because  he  believes  that  a  more  flexible  architecture  than  the  current 
one  is  needed. 

•  8.  The  asset  producer,  broker,  and  consumer  roles  are  distinct  within  Reuse 
Engineering. 

Jane  in  scenario  1  maps  the  activities  in  the  FPD  plan  to  the  Reuse  Engineering  families 
to  clarify  the  roles  identified  in  the  plan.  In  scenario  2,  Chris  considers  the  distinct  Reuse 
Engineering  roles  in  mapping  the  existing  MSA  organization  to  the  CFRP  and  delineating  the 
scope  of  the  application  engineering  process  being  defined.  In  scenario  3,  Kate  is  addressing 
the  producer  role  but  is  mindful  in  particular  of  the  consumers  when  she  initiates  a  revision 
of  the  domain  analysis  process  to  better  meet  their  needs.  In  scenario  4,  Jack  explicitly  looks 
at  the  many  stakeholders  in  the  VAMOS  environment,  identifies  them  as  creators,  managers, 
or  utilizers,  and  considers  the  numerous  potential  interrelationships  among  them. 

•  9.  The  CFRP  is  generic  with  respect  to  domains,  technologies,  management 
styles,  and  economic  sectors. 

This  theme  is  illustrated  not  by  any  single  scenario  but  rather  by  the  collection  as  a  whole. 
Scenarios  1  and  2  address  the  private  sector,  scenario  3  addresses  the  government  sector,  and 
scenario  4  touches  on  both.  The  scenarios  address  entirely  different  domains,  occur  in  different 
organizational  contexts,  and  zissume  different  types  and  degrees  of  technology  support. 
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•  10.  CFRP  processes  should  be  integrated  with  overall  planning  and  engineering 
practices. 

In  scenario  1,  Jane  follows  the  RedLine  process,  which  has  incorporated  the  Planning,  Enact¬ 
ment,  and  Learning  processes  of  the  Reuse  Management  idiom  into  a  general  document  review 
process.  The  central  focus  of  scenario  2  is  to  tightly  integrate  Asset  Utilization  processes  into 
each  of  the  existing  application  engineering  process  activities.  In  scenario  4,  Jack’s  task  is  to 
infuse  a  reuse  plan  into  the  overall  life  cycle  plan  for  the  VAMOS  effort,  and  he  specifically 
considers  how  to  integrate  Reuse  Management  processes  with  existing  program  management 
processes. 

•  11.  The  CFRP  is  a  process  modeling  language  with  mechanisms  to  support 
composition  of  complex  process  configurations. 

Scenario  3  illustrates  one  aspect  of  CFRP  process  modeling  when  John,  who  is  undertaking 
an  Innovation  Exploration  task,  embeds  a  P-&L  loop  in  his  activity.  Scenario  4  shows  more 
extensive  use  of  CFRP  process  modeling  capabilities.  Jack  realizes  that  he  cannot  plan  the 
reuse  program  in  detail  and  needs  to  create  lower-level  P-E-L  loops  to  do  more  localized 
planning.  He  also  uses  the  notion  of  cascading  C-M-U  idioms  to  understand  some  of  the 
relationships  among  stakeholders  and  recommends  that  a  reuse  assessment  team  produce  a 
more  comprehensive  stakeholder  interaction  model.  In  addition.  Jack  exploits  the  CFRP 
notions  of  a  reuse  program,  reuse  initiative,  and  reuse  cycles  to  model  temporal  relationships 
among  distinct  phases  of  the  program. 

•  12.  The  CFRP  is  scsilable  and  applicable  at  different  organizational  leveb. 

In  scenario  1,  Jane  applies  a  CFRP-influenced  process  at  her  own  individual  level,  and  also 
uses  the  CFRP  to  analyze  a  reuse  plan  for  a  product  division.  In  scenario  3,  John  and  Lee 
apply  the  CFRP  in  a  small  domain  analysis  pilot  effort,  while  Kate  incorporates  the  CFRP 
into  her  overall  project  plan.  In  scenario  4,  Jack  is  planning  at  a  high,  strategic  level  while 
also  “planning  the  planning”  for  individual  program  phases  and  reuse  projects.  Jack  also 
identifies  several  stakeholders  in  the  VAMOS  environment,  from  a  variety  of  organizations 
and  organizational  levels. 

•  13.  The  CFRP  is  a  domain  model  and  high  level  process  architecture  for  the 
reuse  process  domain. 

The  central  focus  of  scenario  1  is  to  use  the  CFRP  as  a  domain  model  against  which  the  FPD 
plan  is  assessed.  In  scenario  3,  Kate  uses  the  CFRP  definition  of  the  Asset  Creation  family 
to  guide  her  understanding  of  the  tasks  to  be  planned. 


The  scenarios  also  show  examples  of  how  the  other  information  included  in  this  document  can  be 
used  to  understand  and  apply  the  CFRP.  In  scenario  1,  Jane  refers  to  the  diagrams  in  Appendix  A 
to  obtain  a  more  detailed  understanding  of  potential  data  flows  among  processes,  in  preparation 
for  analyzing  the  reuse  plan.  In  scenario  3,  Kate  also  reviews  the  diagrams  in  Appendix  A  to 
understand  Asset  Creation  more  fully,  and  John  uses  Appendix  B  as  a  source  of  information  about 
domain  analysis  methods  that  are  consistent  with  the  CFRP.  In  scenario  4,  Jack  uses  Appendix  B 
to  find  products  that  can  help  him  define  a  VAMOS  reuse  adoption  strategy. 
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4  CFRP  Application  Experience  and  Guidelines 


Much  of  this  document  provides  CFRP  application  guidance  that,  while  grounded  firmly  in  the 
experience  and  insight  of  the  document  authors,  is  presented  either  as  theory  (the  general  CFRP 
application  principles  in  Section  2),  interpretation  (the  example  CFRP  IDEFo  process  model  in 
Appendix  A,  or  instructive  fiction  (the  CFRP  application  scenarios  in  Section  3). 

This  section  complements  those  portions  of  the  document  with  information  that  more  directly 
reflects  practical  experiences  with  the  CFRP.  It  includes  a  summary  of  actual  uses  of  the  CFRP 
to  date  and  provides  a  preliminary  set  of  practical  guidelines  for  getting  started  with  the  CFRP, 
based  on  user  feedback.  This  material  may  be  expanded  in  the  future  to  provide  more  detail  or 
more  definitive  guidance. 


4.1  Practical  Application  of  the  CFRP  to  Date 

Although  the  scenarios  provide  coherent  stories  illustrating  how  the  CFRP  can  be  used,  they  do  not 
represent  case  studies  describing  actual,  practical  applications  of  the  CFRP.  A  significant  amount 
of  practical  CFRP  experience  is  being  recorded  through  both  internal  STARS  efforts  and  the 
initiative  of  external  organizations  interested  in  the  CFRP.  None  of  that  experience  has  yet  been 
documented  in  as  detailed  and  coherent  a  form  as  the  scenarios,  so  no  actual  CFRP  application 
efforts  are  described  in  detail  in  this  document.  Instead,  several  such  efforts  are  summarized  briefly 
below  to  help  trigger  additional  ideas  for  applying  the  CFRP  and  to  show  that  the  CFRP  is  proving 
useful  to  a  number  of  organizations  in  a  number  of  ways. 


STARS  Application 

STARS  has  used  the  CFRP  internally  in  a  wide  variety  of  ways.  One  approach  has  been  to  use  the 
CFRP  at  a  high  level  as  a  process  checklist  or  as  a  means  of  organizing  products.  For  example, 
a  TRW  STARS  team  compared  the  processes  designated  in  the  CFRP  against  their  reuse-based, 
risk-driven  spiral  model  for  Ada  development  [Sof91b]  to  help  validate  both  their  model  and  the 
CFRP.  A  joint  STARS  group  used  the  CFRP  to  facilitate  process  planning  by  identifying  which 
reuse-based  process  definitions  are  available  today  and  which  process  definitions  would  likely  be 
needed  for  the  STARS  demonstration  projects  (see  below).  This  same  group  used  the  CFRP  as  an 
organizing  principle  in  packaging  STARS  and  other  reuse-related  products  to  support  the  STARS 
Reuse  Technology  Transition  Afldliates  program  (a  program  being  sponsored  by  STARS  to  foster 
trial  usage  of  the  packaged  products  by  external  organizations  and  to  promote  involvement  of  those 
organizations  in  STARS  technical  activities). 

STARS  has  also  applied  the  CFRP  more  deeply  in  a  variety  of  contexts,  such  as  in  using  the  CFRP 
as  a  key  conceptual  foundation  for  a  collection  of  reuse-based  process  models.  Unisys  is  defining 
two  process  models  that  are  directly  derived  from  or  strongly  incorporate  CFRP  principles:  the 
Reuse- Oriented  Software  Evolution  (ROSE)  life-cycle  process  model  and  the  Organization  Domsdn 
Modeling  (ODM)  domain  analysis  process  model.  The  ROSE  model  [Sof93e]  specializes  the  CFRP 
and  extends  it  to  cover  the  entire  software  engineering  life  cycle  to  provide  specific  yet  tailorable 
guidance  in  the  activities  that  are  involved  in  operating  a  reuse  program  in  accordance  with  CFRP 
principles.  ROSE  strongly  reflects  CFRP  structure  via  partitioning  into  four  distinct  submodels: 
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an  overall  Organization  Management  process  model  and  Domain  Engineering,  Asset  Management, 
and  Application  Engineering  project  process  models.  One  key  emphasis  of  ROSE  is  the  role  of 
domain-specific  reuse  and  re-engineering  on  software  maintenance  and  evolution.  The  ODM  model 
[Sof93a]  directly  integrates  the  CFRP  idioms  with  a  variety  of  modeling  principles  and  techniques 
to  form  a  set  of  processes  that  encompass  both  the  planning  activities  involved  in  selecting  and 
scoping  domains  of  focus,  and  the  domain  engineering  activities  involved  in  creating  and  evolving 
domain  models  and  asset  bases.  ODM  is  also  generally  consistent  with  the  ROSE  model  so  that 
ODM  can  be  readily  applied  in  the  ROSE  context. 

Boeing  has  led  development  of  a  STARS  Reuse  Strategy  Model  [Sof93c]  that  will  enable  projects 
to  assess  their  reuse  capabilities  and  devise  strategies  for  evolving  them.  The  specific  capability 
dimensions  and  indicators  in  the  model  are  strongly  influenced  by  the  CFRP.  Furthermore,  part  of 
the  plan  for  future  evolution  of  the  RSM  is  to  use  the  CFRP  as  a  domain  model  of  reuse  processes 
that  provides  a  classification  structure  for  collecting  and  comparing  data,  metrics,  and  experience 
about  reuse  processes  and  practices.  This  information  will  be  used  to  evolve  the  RSM  over  time 
based  on  empirical  evidence.  The  Boeing  STARS  team  has  also  used  the  CFRP  as  a  basis  for 
a  process  model  that  extends  domain  engineering  concepts  to  address  reuse-based  product  line 
management  [DB92]. 

The  principal  thrust  of  the  STARS  program  at  this  time  is  to  support  the  STARS  demonstration 
projects.  STARS  is  working  with  the  Army,  Navy,  and  Air  Force  to  sponsor  three  DoD  software 
engineering  projects,  with  the  objective  of  demonstrating  the  benefits  of  the  megaprogramming 
paradigm  in  a  realistic  and  familiar  context.  Each  of  these  projects  provides  an  important  set¬ 
ting  in  which  to  apply  the  CFRP  to  reuse  planning.  To  date,  the  Army  STARS  Demonstration 
Project,  supported  by  Unisys,  has  applied  the  CFRP  most  directly  to  their  planning  processes. 
The  project  focus  is  on  re-engineering  an  Army  Intelligence  Electronic  Warfare  (lEW)  application 
while  simultaneously  engineering  a  set  of  domain  assets  within  a  subset  of  that  application  area 
that  will  be  reusable  across  multiple  lEW  applications.  The  project  has  been  strongly  influenced 
by  CFRP  Plan-Enac  earn  principles,  as  seen  not  only  in  their  process  model  definitions,  but  also 
in  the  way  they  have  .ightly  woven  those  principles  into  their  daily  work.  The  project  thus  far  has 
focused  on  using  the  CFRP  as  a  guideline  for  structuring  their  high-level  project  processes,  while 
using  ODM  as  the  basis  for  their  lower-level  domain  engineering  processes.  The  project  is  now 
beginning  to  use  the  ROSE  model  as  a  basis  for  modeling  portions  of  their  overall  project  processes 
at  a  finer  level  of  granularity  than  the  CFRP  offers,  while  retaining  consistency  with  ODM. 


Non-STARS  Application 

The  CFRP  is  also  being  used  in  various  contexts  not  directly  associated  with  STARS  activities. 
A  reuse  initiative  within  a  Boeing  Commercial  Airplane  group  hais  incorporated  key  concepts  of 
the  CFRP,  particularly  the  notion  that  reuse  requires  planning,  investment,  and  management 
of  software  as  assets.  The  CFRP  has  also  influenced  the  design  of  a  Boeing-developed  Cobol 
Reengineering  Workbench  to  provide  reverse  engineering  capabilities  that  support  domain  analysis. 
The  Air  Force  Central  Archive  for  Reusable  Defense  Software  (CARDS)  program,  which  is  already 
a  key  trial  user  of  STARS  technology,  has  evaluated  and,  to  varying  degrees,  used  the  CFRP  as 
an  organizing  principle  for  some  of  their  reuse  products  and  training  materials.  The  Air  Force  has 
also  used  the  CFRP  as  a  basis  for  organizing  aspects  of  their  Software  Reuse  Implementation  Plan. 
The  Institute  for  Defense  Analyses  (IDA),  on  behalf  of  the  DoD,  has  used  the  CFRP  structure  as 
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a  means  for  organizing  information  that  is  being  collected  to  characterize  reuse  success  stories  in 
government  and  industry. 

Hewlett-Packard,  a  Unisys  STARS  Prime  Affiliate  and  STARS  Reuse  Technology  Transition  Af¬ 
filiate,  has  begun  using  the  CFRP  intemaUy  in  two  activities.  In  one,  a  product-development 
organization  is  analyzing  its  current  software  development  process,  then  developing  an  improved 
process  based  on  integrating  the  CFRP  model  with  the  existing  process.  Participants  are  receiving 
training  to  better  understand  the  CFRP,  as  well  as  training  in  process  analysis  and  modeling.  In 
the  other  project,  the  centralized  corporate  organization  that  provides  expertise  in  software  reuse 
has  developed  a  general  reuse  process  model.  They  have  used  the  CFRP  as  a  checklist,  against 
which  to  evaluate  and  improve  the  general  reuse  process.  This  model  is  the  basis  for  training  in 
reuse  concepts  and  hands-on  training  in  asset  engineering  activities. 


4.2  Getting  Started  with  the  CFRP 

Early  feedback  from  CFRP  application  efforts  has  suggested  several  preliminary  hints  and  guidelines 
for  getting  started  with  the  CFRP.  These  are  described  concisely  below. 

Prospective  users  of  the  CFRP,  after  absorbing  the  CFRP  Definition  and  Application  documents, 
should  be  able  to  approach  reuse  tasks  with  a  more  comprehensive  view  of  what  process-driven, 
domain-specific  reuse  entails.  Nevertheless,  the  CFRP  Application  document,  if  taken  strictly  at 
face  value,  provides  only  a  limited  perspective  on  how  to  apply  the  CFRP,  since  it  covers  only  a 
fraction  of  the  tasks  and  situations  to  which  the  CFRP  can  be  applied.  Readers  must  be  prepared  to 
abstract  and  interpret  the  material  in  the  document  (particularly  the  scenarios)  to  understand  how 
to  apply  the  CFRP  in  their  own  contexts.  The  role  of  the  scenarios  is  thus  mainly  to  inspire  CFRP 
insights  among  prospective  users  in  preparation  for  their  own  specific  reuse  tasks.  Regardless  of  the 
nature  and  size  of  these  tasks,  we  encourage  readers  to  view  their  reuse  work  through  CFRP-tinted 
glasses  and  “live”  the  CFRP  in  their  own  activities. 

Of  course,  learning  to  apply  the  CFRP  will  require  not  only  philosophical  insights  and  perspectives, 
but  also  experience  gained  through  practical  use.  We  suggest  applying  the  CFRP  gradually  within 
an  organization,  in  incremental  steps.  This  can  involve  starting  with  a  small  scale  effort  that  does 
not  address  all  aspects  of  the  CFRP  and  graduaUy  broadening  the  scope  of  the  work  as  appropriate. 
It  is  vital  in  such  contexts  not  to  downplay  the  importance  of  Reuse  Management.  In  particular, 
incremental  approaches  demand  that  objectives  be  established,  results  be  measured  and  evaluated, 
and  lessons  be  learned  to  fuel  improvement. 

One  approach  is  to  start  with  a  personal  pilot  effort.  An  individual  interested  in  introducing 
the  CFRP  within  an  organization  could  use  a  small  pilot  as  an  opportunity  to  get  a  hands-on 
appreciation  for  the  benefits  of  the  CFRP  and  develop  confidence  in  applying  it.  Interpreting  an 
existing  reuse  effort  in  CFRP  terms,  as  done  in  scenario  1,  could  be  a  suitable  pilot.  Writing  a 
plan  for  an  envisioned  reuse  project  within  one’s  organization  could  be  another.  A  more  ambitious 
pilot  would  involve  planning  and  enacting  small  Create,  Manage,  and/or  Utilize  efforts  and  learning 
from  them. 

Experience  with  the  CFRP  has  suggested  some  guidelines  for  applying  the  CFRP  in  detail.  One 
guideline  is  to  recognize  that  the  CFRP  is  a  high  level  framework  and  often  open  to  different,  yet 


Page  51 


30  September  1993 


STARS- VC- A018/002/00 


equally  valid,  interpretations.  In  trying  to  map  a  given  activity  to  the  CFRP,  there  may  be  several 
reasonable  alternatives,  and  none  of  them  may  be  clearly  the  “best”,  due  to  conflicting  criteria  or 
interpretations.  In  such  circumstances,  we  recommend  simply  picking  one  option  and  not  agonizing 
over  the  choice.  The  choice  can  always  be  refined  later  with  the  benefit  of  experience  and  learning. 
Another  guideline  is  to  be  cautious  about  creating  too  many  nested  layers  of  P-E-L  loops  within 
CFRP  models,  because  such  models  can  easily  become  large,  complex,  and  difficult  to  understand. 
Each  P-E-L  loop  should  have  a  scope  or  time  frame  that  is  clearly  different  from  its  parent  loop. 

It  is  unclear  whether  in  the  long  run  the  CFRP  will  be  applied  directly,  as  in  the  illustrative 
scenarios  in  this  document,  or  whether  the  CFRP  concepts  and  structures  will  be  built  into  less 
abstract  process  models  and  methodologies  that  are  applied  in  practice.  In  the  latter  case,  the 
CFRP  would  provide  the  conceptual  foundation,  but  would  not  be  used  as  the  primary  source  of 
information.  We  invite  feedback  from  any  use  of  the  CFRP  to  help  shape  its  further  development 
and  to  indicate  the  type  of  application  guidance  that  will  be  most  valuable. 
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A  CFRP  IDEFo  Process  Model 


This  appendix  provides  an  example  of  how  the  CFRP  can  be  modeled  using  the  IDEFo  notation. 
It  includes  a  set  of  IDEFo  diagrams,  followed  by  a  data  dictionary  that  describes  the  meaning  of 
each  of  the  data  items  flowing  between  process  categories  in  the  diagrams. 


A.l  IDEFo  Diagrams 

The  IDEFo  process  model  diagrams  appear  on  the  pages  that  foUow.  The  order  in  which  the 
diagrams  appear  is  consistent  with  the  hierarchical  idiom/family  decomposition  structure  of  the 
CFRP  and  should  be  straightforward  to  follow.  The  only  deviation  from  the  CFRP  family  structure 
is  that  the  Asset  Management  process  family  is  broken  into  two  diagrams,  a  Manage  Assets  diagram 
that  encompasses  all  of  Asset  Management,  and  a  Pofhdate  Library  diagram  that  focuses  on  the 
Asset  Management  activities  associated  with  populating  an  asset  library  with  individual  assets. 

The  process  categories  and  data  flows  in  this  IDEFo  model  illustrate  one  interpretation  of  the 
CFRP,  designed  to  be  highly  consistent  with  the  canonic  CFRP  as  described  in  the  CFRP  Defini¬ 
tion  document.  Organizations  can  use  this  model  directly  as  a  basis  for  additional  IDEFo  CFRP 
modeling  (e.g.,  modeling  the  CFRP  in  more  detail  or  modeling  alternative  CFRP  configurations). 
They  can  also  adapt  the  process  categories  and  data  flows  to  address  their  specific  needs,  while  stUl 
conforming  to  the  CFRP  process  idiom  and  family  structure,  or  they  can  integrate  the  model  (or 
some  adaptation  thereof)  with  existing  IDEFo  process  models. 

IDEFo  is  becoming  an  increasingly  popular  process  modeling  notation,  but  not  aU  readers  of  this 
document  may  be  familiar  with  it.  The  following  is  a  brief  overview  of  the  notation: 


An  IDEFo  activity  diagram  contains  one  level  of  decomposition  of  a  process.  Boxes 
within  a  diagram  show  the  subactivities  of  the  parent  activity  named  by  the  diagram. 
Arrows  between  the  boxes  show  the  flow  of  information  among  activities.  Arrows  en¬ 
tering  the  left  side  of  a  box  are  inputs  to  an  activity,  arrows  exiting  the  right  side  of 
a  box  are  outputs  from  the  activity,  arrows  entering  the  top  of  a  box  are  controls  that 
regulate  the  activity,  and  arrows  entering  the  bottom  of  a  box  are  mechanisms  that  sup¬ 
port  the  activity.  A  sequential  ordering  of  boxes  in  a  diagram  implies  some  information 
flow  dependency  between  the  activities,  but  does  not  imply  a  sequential  flow  of  control 
between  the  activities.  Any  activity  can  be  further  decomposed  into  another  IDEFo 
diagram  describing  its  subactivities. 


See  [SofSl]  for  more  details  on  the  notation  syntax  and  semantics. 
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A. 2  Data  Dictionary  for  IDEFo  Diagrams 

The  following  data  dictionary  contains  a  description  of  the  inputs,  outputs,  controls,  and  mecha¬ 
nisms  in  the  IDEFq  diagrams.  Descriptions  of  the  processes  can  be  found  in  the  CFRP  Definition 
document. 


Acceptance  Constraint  A  policy,  legal,  or  domsdn-specific  constraint  that  must  be  satisfied  by 
a  submitted  asset  to  be  accepted  for  inclusion  in  the  asset  library. 

Accepted  Asset  A  submitted  asset  that  satisfies  all  acceptance  constraints  for  inclusion  in  the 
asset  library. 

Architecture  Asset  A  reusable  software  architecture  applicable  to  multiple  systems  within  a 
domain.  The  architecture  defines  an  organizing  framework  for  constructing  new  application 
designs  and  implementations. 

Assessment  A  characterization  of  the  current  state  of  reuse  practice  within  a  reuse  program’s 
scope  of  planning,  the  readiness  of  the  organization  as  a  whole  (or  of  specific  groups)  for 
practicing  reuse-based  software  engineering,  and  the  reuse  technology  and  expertise  available 
both  internal  and  external  to  the  organization. 

Asset  A  unit  of  information  of  current  or  future  value  to  a  software  development  or  maintenance 
enterprise.  Assets  can  include  a  wide  variety  of  items,  such  as  software  life  cycle  products, 
domain  models,  processes,  documents,  case  studies,  research  results,  presentation  materials, 
etc. 

Asset  Criteria  Criteria  for  identifying,  selecting,  and  tailoring  assets  in  order  to  reuse  them  for 
some  purpose. 

Asset  Library  A  set  of  assets  and  associatt-d  services  for  accessing  and  reusing  the  assets.  A 
library  typically  consists  of  assets,  corresponding  asset  descriptions,  a  library  data  model, 
and  a  set  of  services  (manual  or  automated)  for  managing,  finding,  retrieving,  and  reusing 
assets.  Such  services  can  include  reuse  consultation  services. 

Asset  Specification  A  specification  describing  the  characteristics  of  assets  that  are  to  be  imple¬ 
mented.  Assets  are  specified  in  terms  of  the  range  of  features  or  characteristics  they  should 
support.  The  methods  and  technologies  that  should  be  used  to  develop  the  assets  may  also 
be  specified. 

Candidate  Asset  An  asset  that  has  been  identified  as  a  candidate  for  reuse  in  accordance  with 
some  asset  criteria. 

Certification  Category  A  category  to  which  an  asset  is  assigned  to  indicate  the  degree  of  con¬ 
fidence  that  has  been  established  about  the  asset  relative  to  some  set  of  criteria,  such  as 
functional  correctness,  reliability,  and  adherence  to  standards. 

Committed  Resources  Items  of  value  that  are  allocated  to  support  reuse  projects,  such  as  fund¬ 
ing,  staffing,  needed  expertise,  and  technology  to  be  acquired. 

Consultation  A  service  provided  to  assist  a  user  of  an  asset  library  in  using  the  library  tools, 
locating  needed  assets,  reusing  the  assets,  etc. 
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Development  Guidelines  Guidelines  followed  during  Asset  Implementation  to  increase  the  like¬ 
lihood  that  the  assets  will  be  reusable  and  of  high  quality.  These  development  guidelines 
should  emphasize  good  software  engineering  practices  and  principles. 

Donoain  Knowledge  Information  about  a  domain  in  a  form  other  than  legacy  systems.  This 
knowledge  can  be  imparted  in  a  variety  of  ways. 

Domain  Model  A  definition  of  the  characteristics  of  existing  and  potential  future  products  within 
a  domain  in  terms  of  what  the  products  have  in  common  (their  ‘^commonality” )  and  how  they 
may  vary  (their  “variability”). 

Enactment  Plan  The  portion  of  a  plan  defined  in  Project  Planning  that  specifically  addresses 
and  constrains  Reuse  Enactment  activities.  The  enactment  plan  defines  program  objectives, 
target  domains,  measurement  criteria,  and  individual  project  and  infrastructure  plans. 

Enactment  Process  A  process  defined  in  Project  Planning  that  is  specifically  enacted  to  perform 
Reuse  Enactment  activities. 

Existing  Infrastructure  The  infrastructure  already  in  existence  during  the  planning  activities 
of  a  reuse  program. 

Feedback  Reactions  and  lessons  learned  from  the  use  of  the  reuse  program’s  assets,  plans,  and 
services.  This  feedback  can  include  information  about  shortcomings  in  reuse  plans.  Asset 
Management  services,  domain  models,  and  domain  architectures  and  other  assets. 

Implementation  Asset  Any  asset  (other  than  an  architecture  asset)  applicable  to  the  imple¬ 
mentation  of  multiple  systems  within  a  domain.  The  asset  can  be  a  component  (i.e.,  reusable 
directly  to  form  an  application  product,  perhaps  with  some  tailoring)  or  a  generator  (i.e.,  a 
tool  that  generates  application  products  based  on  a  specification  of  desired  product  charac¬ 
teristics). 

Improvement  Opportunity  An  opportunity  for  improving  the  current  state  of  the  reuse  pro¬ 
gram,  based  on  recommendations  and  lessons  learned  from  the  Reuse  Learning  activities  and 
insights  gained  during  Assessment  activities. 

Infrastructure  Plan  A  plan  for  meeting  the  common  technical,  organizational,  and  educational 
needs  for  all  projects  within  the  current  scope  of  planning. 

Innovation  New  ideas,  discoveries,  and  innovative  products  that  can  improve  the  processes,  in¬ 
frastructure,  or  assets  within  the  reuse  program. 

Innovative  Technology  Technology'  of  a  new  or  innovative  nature  (relative  to  a  given  organi¬ 
zation),  available  from  external  sources  such  as  the  research  community,  marketplace,  or 
publicly  available  asset  bases. 

Learning  Plan  The  portion  of  a  plan  defined  in  Project  Planning  that  specifically  addresses  and 
constrains  Reuse  Learning  activities. 

Learning  Process  A  process  defined  in  Project  Planning  that  is  specifically  enacted  to  perform 
Reuse  Learning  activities. 

Lessons  Learned  Results  of  Project  Evaluation,  propagated  and  possibly  filtered  by  Enhance¬ 
ment  Reconomendation,  that  reflect  what  has  been  learned  about  a  project  during  its  enact¬ 
ment. 
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Library  Data  Model  A  data  model  for  describing  assets  in  an  asset  library.  The  model  should 
include  the  information  that  most  directly  and  appropriately  supports  the  Asset  Utilization 
processes  of  prospective  library  users  (and  it  should  structure  the  information  accordingly). 

Managed  Asset  An  asset  that  has  been  incorporated  into  the  library  and  made  accessible  to 
library  users.  A  managed  asset  has  an  accompanying  asset  description  containing  information 
about  the  asset  that  aids  user  understanding  and  evaluation  of  the  asset. 

Market  Forces  New  market  trends,  competitive  developments,  new  technologies,  emerging  stan¬ 
dards,  and  other  factors  that  impact  perception  of  marketplace  needs. 

Objectives  Specific  reuse  objectives  defined  for  the  reuse  program  as  a  whole. 

Organizational  Context  The  business  strategies,  policies  and  procedures,  expertise,  technolog¬ 
ical  capabilities,  cultural  legacies,  etc.,  of  the  set  of  organizations  involved  in  a  reuse  effort. 

Organizational  Infrastructure  Plan  A  plan  for  meeting  the  common  organizational  needs  for 
all  projects  planned  within  a  reuse  program.  Organizational  infrastructure  can  include  coor¬ 
dinated  team  activities,  funding  models,  incentive  strategies,  risk  reduction  measures,  organi¬ 
zational  policies  and  procedures,  project  role  definitions,  reuse-oriented  task  forces,  transition 
teams  and  steering  committees,  and  so  on. 

Other  System  Element  An  application  system  element,  not  derived  from  a  reusable  asset,  with 
which  tailored  assets  are  integrated. 

Packaged  Experience  Project  measurement  and  history  data  that  has  been  packaged  into  struc¬ 
tured  knowledge  to  facilitate  systematic  learning. 

Plan  A  reuse  program  plan,  including  explicit  objectives  and  strategic  decisions,  target  domains 
and  other  scoping  decisions,  proposed  reuse  infrastructure  capabilities  to  be  acquired  or  devel¬ 
oped,  reuse  projects  and  project  interrelationships  to  perform  the  proposed  work,  and  criteria 
and  metrics  for  evaluating  the  success  of  the  program. 

Potential  Asset  An  artifact  obtained  from  some  relevant  source  (e.g.,  another  asset  library,  an 
existing  software  system  within  a  relevant  domain)  that  is  a  candidate  for  inclusion  in  an 
asset  library. 

Process  A  description  of  a  series  of  steps,  actions,  or  activities  to  bring  about  a  desired  result. 
The  process  may  be  expressed  at  various  levels  of  abstraction,  reflecting  the  various  degrees  of 
precision  appropriate  at  different  organizational  levels  and  at  different  stages  in  the  definition 
of  a  overall  life  cycle  process.  Depending  on  the  level  of  abstraction  at  which  a  process  is 
described,  it  may  or  may  not  include  well-defined  inputs,  intermediate  products,  constraints, 
needed  resource  descriptions,  outputs,  and  testable  criteria  for  starting,  stopping,  and  moving 
on  to  the  next  step  in  the  series. 

Program  Evaluation  Criteria  The  criteria  for  evaluating  how  successfully  a  reuse  program’s 
objectives  have  been  met. 

Project  History  Qualitative  historical  information  about  the  project  processes,  products,  and 
infrastructure. 
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Project  Measurement  A  quantitative  measurement  collected  during  project  enactment  to  mea¬ 
sure  the  effectiveness  of  the  project  processes  and  reuse  infrastructure,  as  well  as  the  quality 
of  the  products  produced  by  the  processes  and  infrastrr  cture. 

Project  Plan  A  detailed  plan  of  the  Reuse  Engineering  projects  that  will  be  enacted  within  a  reuse 
program.  The  project  plan  includes  the  identity  of  the  individual  projects  and  specification 
of  the  relationships  and  interconnections  among  the  projects.  It  also  includes  definitions  of 
the  specific  processes,  evaluation  metrics,  budget,  schedules,  resource  needs,  and  potential 
payoff  for  each  project. 

Recommendation  A  suggestions  for  changes  to  the  reuse  program  strategy  or  plams,  reuse  in¬ 
frastructure,  reuse  processes,  or  reuse  products,  based  on  the  results  of  learning. 

Rejected  Asset  A  submitted  asset  that  does  not  satisfy  all  library  acceptance  criteria  and  is 
therefore  rejected  for  inclusion  in  the  asset  library. 

Reuse  Infrastructure  The  collection  of  capabilities  that  is  needed  to  support  and  sustain  reuse 
projects  within  a  reuse  program.  Includes  tools  and  technology;  organizational  structure, 
policies  and  procedures;  and  education  and  training. 

Scoping  Decision  A  decision  about  the  overall  scope  of  a  reuse  program.  Such  decisions  can 
Involve  selection  of  application  product  lines  to  be  produced  based  on  domain  assets,  selection 
of  specific  domains  that  will  be  engineered  to  support  the  product  lines,  identification  of 
specific  client  or  stakeholder  groups  for  the  engineered  domains,  more  traditional  definition 
of  engineering  scope  for  individual  tasks,  etc. 

Selected  Asset  An  asset  selected  for  reuse  in  accordance  with  some  asset  criteria. 

Software  System  A  software  application  system  encompassing  one  or  more  domaln(s)  of  interest. 

Software  System  Needs  Overall  application  system  requirements  including  user  requirements 
and  any  reuse-related  requirements  governing  specific  asset  characteristics. 

Strategic  Goals  Goals  determined  by  the  high-level  strategies  within  a  reuse  program. 

Strategy  An  approach  to  instituting  and  evolving  reuse  capabilities  to  satisfy  overall  objectives 
within  a  reuse  program.  The  strategy  is  generally  targeted  to  address  specific  domains. 

Submitted  Asset  An  asset  or  candidate  asset  that  is  submitted  for  inclusion  in  the  asset  library. 

Tailored  Asset  An  asset  which  has  been  adapted  for  integration  into  a  desired  application  prod¬ 
uct. 

Technology  Technological  capabilities  that  can  contribute  to  the  reuse  infrastructure  within  an 
organization  and  can  be  applied  to  establish  or  automate  reuse  processes. 
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B  A  Mapping  of  Existing  Reuse  Products  to  the  CFRP 


This  appendix  identifies  a  list  of  products  (processes  and  tools)  that  support  reuse  activities  iden¬ 
tified  in  the  CFRP  and  maps  those  products  to  each  of  the  six  CFRP  process  families  to  which 
they  are  applicable.  The  purpose  of  this  appendix  is  to  give  the  CFRP  user  an  indication  of  the 
kinds  of  products  that  are  available  to  support  different  aspects  of  reuse  activity  and  to  provide 
some  specific  pointers  to  products  to  consider  during  project  planning,  process  engineering,  and 
infrastructure  planning  and  implementation. 

This  appendix  consists  of  two  tables,  one  containing  only  STARS  products  (including  ASSET 
products)  and  the  other  containing  non-STARS  products.  These  tables  are  subject  to  the  following 
caveats  and  disclaimers: 


•  Inclusion  of  a  product  in  the  table  of  non-STARS  products  should  not  be  construed  in  any 
way  as  a  STARS  endorsement  of  the  product. 

•  The  set  of  products  presented  here  is  considered  to  be  representative  of  products  available  in 
the  commercial  and  government  marketplace,  but  it  should  not  be  construed  in  any  way  as 
being  complete.  Additional  products  will  be  added  in  future  versions  of  this  document  as  the 
authors  become  aware  of  them  and  as  resources  permit. 

•  In  general,  the  specific  mapping  of  the  products  to  CFRP  process  families  has  not  been 
verified  with  the  product  developers  and  reflects  only  the  authors’  assessments  at  this  time. 

•  One  general  criterion  for  including  a  product  in  this  appendix  was  general  public  availability, 
but  the  authors  do  not  guarantee  avtulability  of  the  products. 

•  Another  criterion  for  whether  or  not  to  include  a  product  in  this  appendix  is  that  a  product 
should  not  be  included  if  it  can  be  used  effectively  in  a  context  where  reuse  is  not  a  principal 
objective.  This  excludes  general  object-oriented  analysis  and  design  methods,  for  example. 


In  each  table,  the  leftmost  column  includes  the  product  name.  Where  appropriate,  at  the  end  of 
each  product  name  there  is  a  reference  to  one  or  more  documents  that  comprise  or  describe  the 
product.  These  references  point  to  bibliographic  entries  in  the  References  section  at  the  end  of 
this  document.  The  second  column  in  each  table  includes  the  source  of  each  product,  i.e.,  the 
organization  or  program  that  produced  the  product.  The  third  column  includes  the  product  type, 
with  values  defined  as  follows: 

•  process  -  a  textual  and/or  graphical  representation  of  a  paradigm,  framework,  methodology, 
process  description,  policy,  etc. 

•  tool  -  an  executable  software  product  that  provides  automated  support  for  one  or  more  reuse 
processes. 

The  other  columns  in  the  tables  correspond  to  the  CFRP  process  families,  and  an  “x”  in  a  column 
implies  that  a  product  is  applicable  to  that  family. 
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B.l  STARS  Products 


r~ 

Reuse  Management 

Reuse  Engineering 

Product 

Source 

Type 

Plan 

Enact 

Learn 

Create 

Manage 

Utilize 

Reuse  Strategy  Model  (RSM)  [Sof93c] 

STARS 

process 

X 

X 

Reuse-Oriented  Software  Evolution 
(ROSE)  [Sof93e] 

STARS 

process 

■ 

■ 

■ 

■ 

H! 

Reuse-Based  Spiral  Life-Cycle  Process 
[Sof91b,  Sof91d] 

STARS 

process 

X 

X 

X 

Organization  Domain  Modeling  (ODM) 
[Sof93a] 

STARS 

process 

X 

X 

X 

Domain  Analysis  Process  Model 
(DAPM)  [Sof91c] 

STARS 

process 

■ 

■ 

■ 

■ 

Reuse  Library  Framework  (RLF) 

[Sof93b] 

STARS 

tool 

■ 

■ 

■ 

H 

Reusability  Guidelines  [Sof89] 

STARS 

process 

X 

ASSET  Operations  Plan  [Ass92a] 

ASSET 

process 

X 

Criteria  and  Process  to  Evaluate  Assets 
[Ass92b] 

ASSET 

process 

X 
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B.2  Non-STARS  Products 


n 


Product 


Source 


III 


Reuse  Management  Reuse  Engineering 


Type  ||P/an  \Enact  \Leam  \\Create  [Manage]  Utilize 


DoD  Software  Reuse  Vision  and 
Strategy  [DoD92] 


Direction  Level  Handbook 
[Cen93a] 


Acquisition  Handbook  [Cen92 


Franchise  Plan  [Cen93b 


Reuse  Adoption  Guidebook 
rVir92b] 


Reuse  Maturity  Framework 
KH91] 


Software  Reuse:  Guidelines  and 
Methods  [HC91] 


DSSA  Process  Life  Cycle 


Reuse-Based  Software 
Development  Methodology 
[KCH+92] 


Process  for  Acquiring  Software 
Architecture  [SHM92] 


Domain  Engineering  Guidebook 
[Vir92a] 


Domain  Analysis  and  Design 
Process  [DIS93] 


Feature-Oriented  Domain 
Analysis  (FODA)  rKCH+901 


JIAWG  Object-Oriented  Domain 
Analysis  (JODA)  [Hol92] 


Library  Interconnect  Language 
Annotated  Ada  (LILEANNA) 
[Tra90] 


CARDS 


CARDS 


CARDS 


VCOE 


Hooper/ 

Chester 


GTE/SEI 


SEI 


MITRE 


VCOE 


process 


process 


process 


process 


process 


process 


process 


process 


process 


process 


process 


DISA/CIM  Iprocess 


JIAWG 


jpiocess 


process 


process 


Inquisix 


Reusability  Search  Expert 
(ReuSE) 


Defense  Software  Repository 
System  (DSRS) 


Universal  Network  Architecture 
Services  (UNAS) 


Strategic  Networked  Applications 
Platform  (SNAP) 


l^ansportability  Guideline  for 
Ada  Real-Time  Software  [Lab89] 


Real-Time  Requirements  Annex 
for  Ada  Reusability  [Com90] 


An  Approach  for  Constructing 
Reusable  Software  Components  in 
Ada  [Edw90] 


Ada  Style  Guide 


Library  Operation  Policies  and 
Procedures  [Cen93c] 


CTA  tool 


SPS  tool 


Westinghouse  tool 


DISA/CIM  tool 


Te 

So 


CECOM 


CECOM 


SPC 


CARDS 


■process 


process 


process 


process 


process 
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